Fork me on GitHub
#polylith
<
2022-05-30
>
ikitommi13:05:42

how can I run tests of a component that is not (yet) used in any base? test brick:xyz doesn’t do anything unless the component is used in a base. Or am I missing something?

ikitommi13:05:07

another: running tests of a component used in multiple bases, makes the component tests are run once for each base. Used in 6 bases -> the tests are run 6 times. Is this intentional?

furkan3ayraktar15:05:26

Tests run in the scope of each project. In order to run tests in isolation, Polylith tool creates a new classloader with correct bricks and dependencies for each project. Since the tests might fail (e.g. they are not unit and depend on other component functionality) based on the project that the component is included, they run for each project that the component is included. 👉 Detailed documentation about testing is https://polylith.gitbook.io/poly/workflow/testing.

furkan3ayraktar15:05:32

tl;dr; • component should be included in a project in order to run test, or at least in the development project • tests run for each project that component is included

furkan3ayraktar15:05:25

You can override the default behavior and tell that, lets say, only one project should run the tests and the rest shouldn’t. You can specify a vector of components for each project that the tests should run. If you provide an empty vector, no tests run for that project. You can check Polylith’s own https://github.com/polyfy/polylith/blob/master/workspace.edn as an example which instructs api project should not run any tests but poly should. Development project does not run tests by default.

seancorfield15:05:10

@U055NJ5CC If you do test :dev brick:xyz it should run (because all bricks should be listed in the :dev project).

ikitommi19:05:30

@U04V70XH6 that did the trick, thanks!

ikitommi19:05:31

maybe worth adding to docs?

zharinov20:06:54

Am I correct that, using another words, this testing duplication design addresses the case of A depending on B in one project and A depending on B’ (same interface) in another one?

seancorfield21:06:59

That is certainly one aspect of it (we have two swappable components that each have different implementations in two different projects). Projects may also have different 3rd party library versions (that has been true for us for quite a while, up until recently, so we needed to test several bricks against the appropriate versions of 3rd party libraries).

👍 2
seancorfield16:05:24

Found another use case for swappable components last week: we have a "preview" app that provides a small web server that renders HTML templates using Selmer that our UI/UX designer uses when writing templates for email campaigns. They recently asked for new functionality that I implemented as new custom tags in Selmer but that meant adding more bricks to the preview project, which ended up pulling in a lot more libraries and bloating the size of the preview JAR. So I created a swappable implementation of our main i18n component that essentially stubbed out everything the preview app didn't need (it pulls data from a JSON file instead of a database), which eliminated all those extra libraries, removing about 3MB from the JAR. I'll probably refactor the "preview" version of i18n so I don't have to override the resource tag in the preview-web base which will clean up some code.

polylith 4