This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-24
Channels
- # announcements (3)
- # babashka (3)
- # beginners (34)
- # calva (6)
- # cider (4)
- # clerk (5)
- # cljs-dev (1)
- # clojure (47)
- # clojure-europe (41)
- # clojure-norway (1)
- # clojurescript (59)
- # cursive (5)
- # data-science (9)
- # datascript (14)
- # events (1)
- # fulcro (5)
- # guix (14)
- # helix (7)
- # hoplon (5)
- # hyperfiddle (2)
- # kaocha (8)
- # lambdaisland (1)
- # lsp (24)
- # releases (1)
- # scittle (31)
- # shadow-cljs (10)
- # tools-build (2)
Normally you do it the other way around, define suites with specific :test-paths. You don't need to add those to deps.edn because Kaocha will add them to the classpath. The flag you mention disables that behavior. We don't scan the entire classpath because it would be very inefficient, and error prone. We need to load every file we want to consider first, and then we check which vars with test metadata it created. Other reasons are that we need to know which suite a test belongs to, and Kaocha is a tool-agnostic tool, so we don't want to rely on deps.edn/project.clj/build.boot-isms.
@U07FP7QJ0 The reason I define my test paths in aliases is that people might run the tests with the test runner of their choice, for example Cursive integrated test runner. While in CI we'd like to run the kaocha CLI test runner. We have a :test alias that brings the test files in classpath, and we have different runner aliases for each runner that somebody might want to run (Cursive integrated test runner doesn't need a special alias since you run it through the IDE, you only need the :test alias with the paths for your test files).
Thus we already define the test paths in deps.edn. Right now the same paths we are redefining in tests.edn redundantly. I understand what was the intended usecase, but I also feel like I should be able to configure as much as possible through deps.edn if I need to, for scenarios exactly like this.
If you really want to do this then use the hooks plugin, and write a pre-config hook which generates the config.
We added the skip-add-classpath? flag because our classpath munging was sometimes interfering with other tooling. That's only in very specific cases however. If you're seeing weird errors possibly related to classpath issues you can try if setting that flag, and adding your test paths to the classpath manually helps. The vast majority of regular users should not be using that flag.