This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-02
Channels
- # adventofcode (63)
- # announcements (21)
- # babashka-sci-dev (1)
- # beginners (24)
- # biff (2)
- # calva (78)
- # cherry (6)
- # clj-commons (3)
- # clj-kondo (7)
- # clojure (91)
- # clojure-austin (2)
- # clojure-bay-area (6)
- # clojure-denmark (1)
- # clojure-europe (45)
- # clojure-nl (1)
- # clojure-norway (16)
- # clojure-portugal (3)
- # clojure-uk (1)
- # clojurescript (20)
- # conjure (11)
- # datalevin (13)
- # datomic (5)
- # emacs (14)
- # etaoin (15)
- # events (7)
- # fulcro (9)
- # funcool (1)
- # honeysql (26)
- # joyride (4)
- # kaocha (3)
- # lambdaisland (2)
- # malli (7)
- # off-topic (22)
- # pathom (29)
- # portal (58)
- # practicalli (8)
- # rdf (25)
- # reagent (14)
- # sci (3)
- # scittle (37)
- # shadow-cljs (10)
- # slack-help (2)
- # spacemacs (7)
- # sql (7)
- # tools-deps (1)
- # xtdb (2)
Is there a way to fail fast certain tests only? My use-case would be the same as @charliebriggs': fail-fast integration tests, but don't fail-fast unit tests. @charliebriggs has a discussion about this in the past, but there was no explanation what exactly has worked at the end: https://clojurians.slack.com/archives/CCY2V0U6A/p1605193008070800
I haven't found any github issues about this question either amongst the results i got, when i search for fail-fast
.
Now we are keep switching the :fail-fast?
flag in our tests.edn
, depending on the desired behaviour, which is a bit annoying.
We did mark our integration tests with a ^:behaviour
meta tag and we did define a kaocha test suite, like this:
{:id :behaviour
:focus-meta #profile {:default [:behaviour :x]
:ci [:behaviour]}}
I tried to put :fail-fast?
into this definition, but as i gleamed from the kaocha sources, the :fail-fast?
config option is only used during the test plan computation stage and adds an extra kaocha.report/fail-fast
reporter implicitly to the list of reporters, so it wouldn't make sense to have a per-test-suite setting for it, assuming test suites share the reporter stack during a test run...