This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-11-16
Channels
- # adventofcode (1)
- # announcements (16)
- # babashka (7)
- # beginners (77)
- # calva (31)
- # cider (18)
- # clj-commons (16)
- # cljfx (5)
- # clojars (5)
- # clojure (33)
- # clojure-europe (15)
- # clojure-nl (1)
- # clojure-norway (15)
- # clojure-uk (4)
- # clojurescript (1)
- # conjure (1)
- # core-logic (7)
- # cursive (16)
- # data-science (4)
- # datalevin (6)
- # emacs (20)
- # events (5)
- # fulcro (15)
- # holy-lambda (1)
- # introduce-yourself (1)
- # jobs (2)
- # lsp (30)
- # luminus (3)
- # malli (3)
- # membrane-term (19)
- # missionary (62)
- # off-topic (39)
- # pathom (24)
- # polylith (5)
- # portal (9)
- # practicalli (3)
- # re-frame (16)
- # reagent (5)
- # remote-jobs (1)
- # reveal (21)
- # rewrite-clj (8)
- # shadow-cljs (13)
- # spacemacs (23)
- # sql (12)
- # timbre (2)
- # tools-deps (1)
- # xtdb (4)
I would expect so, yes, since the context for running the test could be different across projects.
For example, at work, we have two HTTP client components so a component whose tests depend on HTTP would actually run differently depending on which client implementation a specific project selected.
You can add a :test
key with the value []
or {:include []}
to exclude testing of all bricks of a project in workspace.edn
, key :projects
(read more in the https://polylith.gitbook.io/poly/workflow/testing section). If you are sure that the brick tests would be executed the same in several projects, this can be an option to speed up the testing. It can also be a risk, because if some configuration changes between projects that affects the tests, then that will not be caught by the tests. With that said, the Polylith workspace uses it (excluding the https://github.com/polyfy/polylith/blob/master/workspace.edn tests).