the polylith util component uses both ways at least (https://github.com/polyfy/polylith/tree/master/components/util/src/polylith/clj/core/util/interface)

Hi @U055NJ5CC. I would say we have three cases: 1. We have a single interface namespace where we put all out functions that we expose, and delegate to one or more implementing namespace within the component. 2. We have a single interface namespace where each function keeps its implementation in that namespace without delegating. 3. Split the interface into sub namespaces (and maybe also a "root interface") where each interface namespace is implemented like 1 or 2. Here is how I think about the different choices: 1. This is the "default" choice, because it often keeps the interface clean. 2. If the implementing functions are small, it can sometimes be cleaner to put them directly in the interface. 3. If the component contains two or more "islands of functionality" then it can be convenient to split the interface into sub interfaces, as a way to keep each part more cohesive. An example mentioned in the documentation is when we put Clojure spec code in a separate interface sub namespace. Another is the util component you mentioned.

thanks!

Without seeing your deps.edn files it's hard to comment for sure, but if you have some/lib in two different aliases that get combined in the Clojure CLI / t.d.a you're going to get one overwriting the other -- because deps are a hash map and that's how merge works. This is intentional so you can override library coordinates in different aliases.

yeah, thanks. I get that. it's easier to overwrite with poly/component-name though because usually libs have unique names. easier in my head at least. Wondering if this should be specified in the docs

You can't have multiple bricks with the same name and all your bricks should be poly/<some-name> so you should not use poly/something for anything that isn't a brick.

(but it's just a convention)

You can specify per-project setup/teardown fixtures in workspace.edn -- which is what we do at work to run code before/after each project's test run.

thanks @U04V70XH6 I was/am looking for that. I need to run (hyperfiddle.rcf/enable!) before the tests start. Found docs on the Testing page 🙂

my setup function runs, but RCF tests are not run if the files are under src/ . I added a rcf test under test/ and it runs.

dre.app.sample-rcf-test(
  RCF__4
  RCF__4✅✅
)]

hey @U08BJGV6E any idea about the above? why namespaces under src/ are not found by hyperfidle/rcf ? I have a hunch this is related to how polylith test runner (using polylith-kaocha) handles the paths.

I have rcf tests in normal namespaces and I would like to run them during tests. it does work if the rcf tests are in a test file under test/

so I think I found out why: it only considers files that end with _test . and only under test/ . I added a test file on src/ and another file without test on test/ . Only files ending in _test under test/ works. I wonder if this is something I can change with kaocha config

Check out the ns-patterns config for kaocha

hi, tried this config and it finds tests and RCF tests without -test on test/ path but not RCF tests

#kaocha/v1
{:tests [{:id          :unit
          :test-paths  ["test" "src"]
          :ns-patterns [".*"]}]
 :plugins [:kaocha.plugin/junit-xml]
 :reporter [kaocha.report/documentation
            kaocha.report/dots]
 :kaocha.plugin.junit-xml/target-file "target/junit-app.xml"}

I think you’ll need a kaocha plugin for that

I don’t know whether one exists

it finds RCF tests as well, updated the above

I know RCF tests work on src as well, I tried it without polylith . will try again

> I think you’ll need a kaocha plugin for that what do you mean?

Let’s take a step back as I’m not sure I understand you now. What RCF tests does it find? What RCF tests does it not find?

Running tests for the app project using test runner: polylith-kaocha...
--- unit (clojure.test) ---------------------------[
dre.app.sample-rcf-test(
  RCF__4
  RCF__4✅✅
)
dre.app.sample-test(
  test-sample
    Test example.
)
dre.app.sample(
  RCF__4
  RCF__4✅✅
)]

all of them are on test/ classpath

so these are the ones it finds, right?

I have another RCF test on src/ that is not found

yes

how are these tests defined in code?

(ns dre.analytics.sample
  (:require [hyperfiddle.rcf :refer [tests]]))

(tests
 
 "another one bites the dust"
 (= 1 1) := true
 
 (+ 1 1) := 2
 )

is this under src or test?

src

and how do the ones found under test look?

same file on test

same namespace name too?

no

see names above in test output

are the ones not found in a component/base/project?

in the same base

all files

try removing :test-paths ["test" "src"] from the kaocha config

#kaocha/v1
{:tests [{:id          :unit 
          :ns-patterns [".*"]}]
 :plugins [:kaocha.plugin/junit-xml]
 :reporter [kaocha.report/documentation
            kaocha.report/dots]
 :kaocha.plugin.junit-xml/target-file "target/junit-app.xml"}

run the tests with :verbose and look for a log line that starts with [polylith-kaocha] Evaluating in project:

you should find :src-paths and :test-paths in that line

My assumption is that the path to your tests under src would only appear under src-paths, is that correct?

yeah, you are right

src path contains all paths

is there anything under test-paths?

I’m assuming the paths to the tests the runner does find

test path contains only the test paths

Okay, that’s the problem you got there. From your snippet it appears the tests are being discovered by Kaocha’s (clojure.test) test type discoverer.

That discoverer only looks at test-paths

Fortunately there’s a way to fix that. Outside of polylith, you’d set :test-paths ["test" "src"] in the config

But inside it’s more complicated as poly forwards paths to kaocha

However

There’s a hook in polylith-kaocha to modify the kaocha config before it’s passed to kaocha: https://github.com/imrekoszo/polylith-kaocha/blob/182e88dfb3aebcc4be321130fd7d0e6e77beafc6/workspace.edn#L20

it’s demonstrated in the example project https://github.com/imrekoszo/polylith-kaocha/blob/182e88dfb3aebcc4be321130fd7d0e6e77beafc6/bases/example/test/polylith_kaocha/example/hooks.clj#L11

default is this: https://github.com/imrekoszo/polylith-kaocha/blob/182e88dfb3aebcc4be321130fd7d0e6e77beafc6/components/kaocha-wrapper/src/polylith_kaocha/kaocha_wrapper/config.clj#L60

for projects where this matters, you can add a custom fn that modifies the config so src-paths get added to test-paths or something like that

thanks, I think I can probably manage. let me see. one I figure this out, would it make sense to have a switch / special feature to suport this OOTB?

I could see p-k having some ready-made hook implementations like this that one would just then have to reference from workspace.edn yes

But I’m going to be cautious and say that first there needs to be a proper problem statement

Also, there’s nothing preventing anyone from creating a new github project that provides some of these

your project, your rules. I like RCF tests for unit tests because: • tests are local to code they test • they can be used as docs.

having some support for them OOTB with little effort would be nice

But since the problem you’re facing is not entirely poly-specific, I think the best solution would be a plugin to kaocha itself, which could discover RCF tests properly

for example, there’s the kaocha OOTB plugin that https://cljdoc.org/d/lambdaisland/kaocha/1.68.1059/doc/automatic-spec-test-check-generation - that is written in a way that it looks at the src-paths for fdefs

Having that as a kaocha plugin would benefit users of RCF tests regardless of whether they use poly or not

thanks for the insight, will look into it

So I’d probably start a discussion in #kaocha about it. Perhaps it’s easier than you think

You’re welcome. Let me know if this was indeed the issue

so I think this works, but I am seeing some issues - probably because are using the same namespace in 2 bases. Because all bases are added to the classpath, I think this is an issue. Will try to solve:

(defn post-enhance-config [config opts]
  (println "custom post-enhance-config")
  (let [res (config/default-post-enhance-config config opts)
        {:keys [kaocha/tests]} res
        tests-config (first tests)
        {:keys [kaocha/test-paths kaocha/source-paths]} tests-config
        merged-paths (into [] (concat test-paths source-paths))
        new-tests (assoc tests-config :kaocha/test-paths merged-paths)]
    (assoc res :kaocha/tests [new-tests])))

I get namespace xxxx not found, though the ns should be on the classpath . and that namespace is singular in all files across all bases/ components

I'd probably reverse the logic a bit and do path magic before calling default-post-enhance-config

thanks, this makes the logic smaller, but I still get an error in processing:

(defn post-enhance-config [config opts]
  (println "custom post-enhance-config")
  (let [{:keys [src-paths test-paths]} opts
        opts (assoc opts
                    :test-paths
                    (into [] (concat src-paths test-paths)))]
    (config/default-post-enhance-config config opts)))

so I got RCF tests to work by passing the JVM options via :poly alias. I pushed the code to the PR and will clean the project a bit before requesting a merge. Thanks @U08BJGV6E and everybody for lending a hand. @U08BJGV6E: Would you consider merging the PR? I would like to add some documentation specific to RCF and remove some files before the PR can be squash-merged .

What is the minimal solution needed in the end? JVM options only? Or JVM options plus src+test-paths?

will discover that and document. I need to finish something for work. Right now I am happy it works 🙂

if it’s the former then I don’t think that has anything to do with p-k - it should also work with poly oob

if it’s the latter, then p-k only matters as much as it’s a test runner that is capable of discovering tests from src-paths

(as the rest is done by rcf + jvm opts)

In any case I don’t think this strongly relates to p-k so I think a separate example repo would demonstrate it better (without all the p-k cruft): just the minimal solution to get rcf+poly work. Then we could link to that repo from p-k and potentially elsewhere (rcf, poly etc)

so I managed to create a repro for src/ as well. https://github.com/ieugen/poly-rcf . I needed to add "src" to :test extra-paths for it to work. So these 2 things are needed: jvm option, src paths need to be added to test classpath so converting rfc tests to clojure.test works

Nice, no need for p-k at all. Thank you

I would still ike to use Kaocha - because IMO it has better reporting.

Sure. I meant not needed to get rcf working with poly