Fork me on GitHub
#polylith
<
2022-06-06
>
ikitommi06:06:43

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.

👀 1
yenda08:06:23

Interested in this as well! the ability to use an external test runner was recently added I still have to look at it

imre08:06:49

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

ikitommi08:06:34

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.

imre08:06:16

I haven't worked out how to forward command line args to kaocha, if you have ideas, a pr is welcome in polylith-kaocha

tengstrand08:06:49

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.

imre08:06:27

Since test discovery is the responsibility of the test runners, I don't see how this could be handled outside of them

imre08:06:53

Or at least without their participation

tengstrand08:06:33

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.

imre09:06:00

Certainly