This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-22
Channels
- # aleph (6)
- # announcements (1)
- # babashka (2)
- # beginners (51)
- # calva (14)
- # cider (1)
- # clj-kondo (15)
- # cljs-dev (2)
- # cljsrn (1)
- # clojure (9)
- # clojure-czech (2)
- # clojure-spec (5)
- # clojure-uk (45)
- # clojuredesign-podcast (2)
- # clojurescript (4)
- # clojutre (3)
- # cursive (4)
- # datomic (8)
- # duct (8)
- # jackdaw (1)
- # joker (1)
- # keechma (1)
- # off-topic (127)
- # om (1)
- # reagent (1)
- # reitit (6)
- # shadow-cljs (22)
- # testing (3)
@plexus Wondering about parallelization in Kaocha -- is significant restructuring still a prerequisite? (https://github.com/lambdaisland/kaocha/issues/81, you last commented in April) Can you summarize what that restructuring would be?
hi @U3JH0P5LJ, seems I missed this message earlier. There's a #kaocha channel that I monitor more actively. In short: nothing has changed, and things are unlikely to change unless I decide to seek funding for another round of Kaocha improvements.
There are two sides to this: parallelization in the kaocha runner, and support for parallelization on the test type level. The former is probably not that hard, but it will impact a bunch of things. Test runs are no longer deterministic, so randomization no longer makes sense. fail-fast will only work approximately. On the test type we have to see where there is an assumptions that things run consecutively. E.g. kaocha-cljs will require a lot of work, because we would have to spin up multiple JS environments and distribute work. Not sure what the assumptions are for Cucumber, but I wouldn't be surprised if it blows up when you start using it from multiple threads. For clojure.test tests things should be relatively straightforward.