Fork me on GitHub

Hmm, bin/kaocha <testsuite> is running all test suites but bin/kaocha --focus <testsuite> runs just the specified. one. I thought these should do the same thing?


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


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: - 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


@U1NDXLDUG 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


(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)))


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.

Piotr Roterski12:03:24

hello 👋 I made a tiny PR bumping glogi version in chai - just letting you know in case you missed it, thank you


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

Piotr Roterski14:03:04

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.

❤️ 1

merged it, will try to cut a release tomorrow

🎉 1