This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-03-10
Channels
- # announcements (3)
- # asami (4)
- # babashka (21)
- # beginners (97)
- # calva (32)
- # cider (4)
- # clj-kondo (7)
- # cljdoc (1)
- # clojure (70)
- # clojure-europe (27)
- # clojure-nl (10)
- # clojure-norway (18)
- # clojure-uk (8)
- # clojure-ukraine (1)
- # clojurescript (5)
- # datalevin (7)
- # docker (1)
- # emacs (3)
- # fulcro (4)
- # girouette (4)
- # graalvm (2)
- # graphql (9)
- # gratitude (3)
- # honeysql (4)
- # hoplon (3)
- # hyperfiddle (7)
- # jobs (3)
- # kaocha (31)
- # lsp (23)
- # malli (7)
- # missionary (6)
- # nextjournal (9)
- # off-topic (6)
- # pathom (13)
- # polylith (13)
- # practicalli (3)
- # remote-jobs (3)
- # reveal (7)
- # schema (1)
- # sci (23)
- # shadow-cljs (31)
- # tools-deps (62)
- # xtdb (8)
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
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
@U07FP7QJ0 Here's a simplified repro of my setup https://github.com/miikka/kaocha-focus-repro
@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
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'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) 😛
(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))
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.
hello 👋 I made a tiny PR bumping glogi version in chai https://github.com/lambdaisland/chui/pull/19 - just letting you know in case you missed it, thank you
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.