Clojurians Log v2

hey, I do have that sitting in my inbox! will have it merged soon.

ah, great, thank you and I’m not trying to urge you in any way, I’m patient and grateful for your OSS work. I just know it’s easy to overlook those github notifications hence my message here.

merged it, will try to cut a release tomorrow

ooh polylith + kaocha! We've just began migrating services to polylith and as we currently use kaocha as a test runner I'd love to learn about others' experience with the combination

I'm in the same situation...

Check this issue out then: https://github.com/polyfy/polylith/issues/126 - my mid term plan is to fork/extend the polylith tool so that one could plug in their own test runner to be used via poly test so poly can do all its classpath magic but would leave test discovery and execution to something like kaocha if plugged

Yeah, that would be nice

@plexus Here's a simplified repro of my setup https://github.com/miikka/kaocha-focus-repro

@miikka if polylith is generating the config then verify that it looks correct with --print-config

had a look at the repro, if you do --focus suite-a you can see that the suite-b is getting marked as skipped: :kaocha.testable/skip true,, that seems to not be happening when doing bin/kaocha suite-a

tbh this is a novel use case, completely generating your config in a plugin.

ok, I think I see what's happening. If you give a suite parameter (so without focusing) it filters that out already in a pre-load load, so that it can skip loading and any other processing for that suite. If you say --focus suite then it loads the full test plan, and then marks the things that are not being focused on as skipped.

I thought the pre-load would still happen after the config phase?

I'm not super invested into this approach, it's just occurred to me to try it out when thinking about how to combine Kaocha and Polylith. Polylith's own test runner is not very good (it's just basically clojure.test + magic to construct the right classpath) 😛

wait forget what I said

the test suite handling is handled way at the beginning

https://github.com/lambdaisland/kaocha/blob/main/src/kaocha/runner.clj#L173

(defn apply-cli-args [config args]
  (if (seq args)
    (-> config
        (assoc :kaocha/cli-args args)
        (update :kaocha/tests
                (fn [tests]
                  (let [run-suite? (set args)]
                    (mapv (fn [{suite-id :kaocha.testable/id :as suite}]
                            (cond-> suite
                              (not (run-suite? suite-id))
                              (assoc :kaocha.testable/skip true)))
                          tests)))))
    config))

this is before the config hook runs

we get into these chicken and egg problems sometimes...

I think what you can try is calling apply-cli-args yourself in your plugin once you have the full config

it's a workaround but it's not the worst. You should be able to find a :kaocha/cli-args in the config you are given

It might make sense to pull this apart, only assoc :kaocha/cli-args at the early stage, and then handle the actual filtering later, maybe in the filter plugin

not sure if this will cause any unwanted change in behavior, it seems a fairly harmless change

Right, yeah, calling apply-cli-args would work or implementing the same logic with :kaocha/cli-args . Thanks.

https://clojurians.slack.com/archives/C013B7MQHJQ/p1648480078508249

@miikka ^

they should. Can you share your tests.edn and maybe make a gist of the ouptut of bin/kaocha --print-test-plan <testuite>

Nope. But I'm using a custom plugin (with config hook) to generate :kaocha/tests for our Polylith project, probably something going wrong with that