This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-06-06
Channels
- # announcements (3)
- # asami (41)
- # aws (2)
- # babashka (65)
- # beginners (85)
- # biff (7)
- # calva (10)
- # cider (5)
- # cljsrn (32)
- # clojure (6)
- # clojure-czech (3)
- # clojure-europe (10)
- # clojure-russia (4)
- # clojure-uk (3)
- # clojurescript (5)
- # core-typed (7)
- # data-science (13)
- # datomic (43)
- # etaoin (4)
- # fulcro (22)
- # graphql (3)
- # gratitude (1)
- # helix (1)
- # joyride (2)
- # liquid (10)
- # malli (16)
- # off-topic (10)
- # other-languages (1)
- # polylith (10)
- # reitit (3)
- # scittle (7)
- # shadow-cljs (103)
- # tools-deps (10)
- # vim (9)
- # xtdb (2)
what good/bad practices have emerged on running external integration tests (e.g. testing a 3rd party api sequences, no guarantees that they always pass, e.g. system down) with polylith? without polylith, I would either:
1. push those tests into separate path, separate script just to run those
2. mix with normal tests, tag with ^:external
meta - have kaocha filter those out by default, script to run those
… would like to do 2 with polylith, just not sure how.
Interested in this as well! the ability to use an external test runner was recently added I still have to look at it
Afaik the poly team's recommendation is to keep quick tests with the bricks and put slow tests into projects but this might not fully map to Tommi's question
Thanks. Putting tests into projects is a good idea, but would still like to have a filter "run only when I asked to" as the tests can be flaky, and should not run by default, even if the project needs to change.
I haven't worked out how to forward command line args to kaocha, if you have ideas, a pr is welcome in polylith-kaocha
It feels like being able to turn on/off tests could be convenient regardless of which test runner you use. We should spend some time to figure out how to best support this.
Since test discovery is the responsibility of the test runners, I don't see how this could be handled outside of them
We can exclude which bricks to test per project today in workspace.edn
in the :test
key for each project. I was thinking that we maybe could have some other test configuration as well to support this use case. Worth thinking about.