Support scanning tests in src directories

[tengstrand]

People sometimes put test code together with the src code. Today we don't run those tests. It would be good if this could be configurable.

To turn it on globally, we could put an :include-src-dirs flag in workspace.edn at the root to affect all tests:

{
 ...
 :test {:include-src-dirs true}
}

or per project:

{
 ...
 :projects {"myproject" {...
                         :test {:include-src-dirs true}}
}

or even per brick:

{
 ...
 :bricks {"mybrick" {...
                     :test {:include-src-dirs true}}
}

[marksto]

Totally support this feature of poly test, but I must admit that I never run into the problem myself, neither with rcf nor with rich-comment-tests on a Polylith-based project that used both.

[seancorfield]

I use rich-comment-tests (per marksto above) but we follow the recommendation in RCT to have a stub file in the test tree that calls into the relevant source ns to actually run the inline tests as part of regular testing.

I would never want src folders scanned for tests but this seems like a harmless (if somewhat pointless) enhancement as long as it is OFF by default.

Plenty of tooling out there doesn't support tests in src and I call it out as a problematic approach in the Expectations documentation because of that.

[tengstrand]

This issue was created to make it easier to work with Hyperfiddle rcf as described here. As it is today, you can add the src directory to the test paths to achieve this, but making it configurable would make it easier for these users. I can't estimate how important this is and if it's worth supporting. Sean points out that it's a problematic approach. What do you say @ieugen?

[ieugen]

hi @tengstrand , I am a bit unsure after reading the comments.

I will try out https://github.com/matthewdowney/rich-comment-tests and probably migrate to it - since it seems a bit less intrusive than RCF .

In gradle, src classes are available for tests on the classpath. Not sure why with clojure is (seems) different.

If the feature is easy to implement and maintain than I am ok with the approach. As an alternative to a feature that would need to be maintained, this could be fixed via improving documentation maybe?

My experience with Clojure is a bit more limited than some. I do have experience from Java land and gradle specifically and I remember this diagram https://docs.gradle.org/current/userguide/java_library_plugin.html#sec:java_library_configurations_graph .

In gradle, testClasspath contains/has access to compileClasspath . I guess for clojure this is a bit different since clojure has the reader ?!?

[seancorfield]

FWIW, the https://github.com/seancorfield/polylith-external-test-runner supports :include-src-dir true (as well as :focus which lets you either specify a list of specific test :var fully-qualified symbols to run or metadata-based :include / :exclude -- mimicking Cognitect's test-runner options).

Polylith 0.2.20 (SNAPSHOT) supports a :test-configs map in workspace.edn that lets you provide named sets of test runner options,