Separate test source path about boot-test

[micha]

What is the purpose of the separate configuration?

[micha]

I'm going to close this ticket because test sources can be handled as described in the Boot for Leiningen Users wiki page. If this doesn't do what you need please feel free to reopen the issue or create a new one :)

[mbuczko]

Well, actually it would be really nice to have this kind of separate config. This way one wouldn't have to wrap "test" task into additional one only to set a tests path. I guess this is the only way now to tell boot-test where tests are located?

(deftask app-test
  "Runs tests"
  []
  (set-env! :source-paths #{"test"})
  (test))

boot-midje has solved that nicer IMHO by introducing test-paths parameter.

[micha]

@mbuczko Why not just add "test" to your :source-paths or :resource-paths along with your other source code? When don't you want tests to be on the class path?

[mbuczko]

I might be wrong, but wouldn't "test" dir be included into uberjar in this case?

[micha]

@mbuczko Things in :resource-paths are on the class path and packaged in JAR files or other kinds of packaging. Things in :source-paths are on the class path but not packaged in JAR files or other packaging. So you can do it either way.

The "input files" and "output files" setup is described in more detail here.

[mbuczko]

@micha I did a test on this repo. I moved test.clj into test/adzerk/boot_test/ and called boot aot -a uber jar (with :source-paths = #{"src" "test"}). resulting project.jar contains compiled test.clj classes.

this is exactly scenario I wanted to solve with additional :test-paths, to keep test/ directory on the class path and exclude it from aot-uber-jar combo. I couldn't find any way of making it working other than wrapping tests into separate task which adjusts :source-paths dynamically.

[micha]

@mbuczko Ah, I see now. Thanks for being patient. I think perhaps we want to add an option to the test task, so you could do:

(task-options!
  test {:source-paths #{"test"}})

or at the command line

boot test -s test

The test paths configuration shouldn't be part of the env, probably, as it's really specific to this one task.

[mbuczko]

@micha yup, that would solve the issue. the only problem is, while testing we usually still need original :source-paths for the code to be tested, so overriding this path would cause most of tests failing (unless it's set as {:source-paths #{"src" "test"}). I guess this is why @pasviegas proposed a parameter exclusively for tests directory (as it would not override original :source-paths this way) and honestly I like it too as it's exactly how midje (and thus boot-midje) solved that problem. lastly, having it consistent across multiple "testing" tasks (eg. boot-test and boot-midje) would look much nicer :)

[micha]

@mbuczko The :source-paths parameter of the test task would merge its paths into the main env, not replace them. Perhaps a better name for the option would be :extra-source-paths or something.

[micha]

I am pretty sure we don't want to introduce coupling of tasks via the env map. There are currently no tasks that need to look at the env map, which is really good because once we start making the env map into a global database we no longer have scopes, which is a huge thing in a Lisp. This is one of the things that makes it difficult to compose leiningen tasks.

So I'm not sure exactly what the best way is yet, but I'm pretty certain that adding keys to the env map is not what we want.

[mbuczko]

Well, I thought rather about a parameter to boot-test task (named :test-paths) rather than variable hold in global env (like :source-paths). This way we could easily modify testing dir within one task and have this parameter named intuitively, just like in the other one. In my case it's quite handy as I use boot-test for acceptance tests (based on kerodon) and midje for all the other tests. Having to remember how each of these tasks configure their directories is now a bit cumbersome. With test-paths param for boot-test all goes down to:

(task-options! midje {:test-paths "test/unit"}
               test  {:test-paths "test/features"})

This way we have test dirs configured for each task separately, they're in classpath but are not in the output of aot-uber-jar.

[kul]

Hi I would second this to be reconsidered,

Not for usability reasons but behavior. So if you have custom tasks defined in source file in a folder eg.
src/boot. Running boot test tries to load that file also for testing which is doomed to fail as one would most likely have boot.core required which is not available in a pod which would be running tests.

Even :exclusions do not help here as it still tries to load the ns.

A :test-paths would just be used to find namespaces to test instead of everything in the classpath
by using c.t.n.f/find-namespaces-in-dir maybe?