core
namespace in the user
component by adding an extra !
, that should do the trick:diff
command, which will give us this output:info
command again:user
component is now marked with an asterisk, *
. If we look carefully we will also notice that the status flags stx
under the cl
column now has an x
in its last position. As we already know, this means that the tests for user
and cli
will be executed from the command-line
project if we execute the test
command.cli
marked to be tested? The reason is that even though cli
itself hasn't changed, it depends on something that has, namely the user
component.development
project are all marked as st-
. The reason the development
project is not marked to be tested is that the development
project's tests are not included by default.interface-test
namespace in the user
component:Tools > REPL > Load File in REPL
Tools > REPL > Run Tests in Current NS in REPL
Tools > REPL > Run Test under carret in REPL
!
so now we need to update the corresponding test accordingly:test
command will pass too:development
project when we run the test
command. But there is a way to do that, and that is to pass in :dev
.info
command first:development
and the command-line
project is marked for test execution. Note: In version 0.2.13-alpha and earlier,project:dev
was an alias for:dev
, which meant that it behaved the same as passing inproject:dev
and as a result, it only included development in the test execution.From version 0.2.14-alpha and later, this has changed so that:dev
means "also include development" without excluding any other projects. Another difference is thatpoly test :all project:p1
in 0.2.13-alpha ran all tests for all projects (because we passed in:all
) but from version 0.2.14-alpha that statement means "run all tests for project p1".
project:dev
or project:cl:dev
(both project alias and name can be used). If development is given, it will automatically be included as if :dev
was passed in:poly info project:dev
poly info project:cl:dev
cl
project are marked to be tested.cli
brick:brick:cli
parameter is just a filter that is applied after the other status calculations have been performed.cli
tests to be executed, we need to pass in :all-bricks
(or :all
if we also want to execute the project tests):cli
brick is now marked to be tested!brick:cli:user
. Another trick we can do is to exclude all bricks with brick:-
which can be useful in combination with :project
or :all
to execute only the project tests.command-line
project.test
directory for the command-line
project:projects/command-line/deps.edn
:./deps.edn
:project.command-line.dummy-test
namespace to the command-line
project:se.example.project.command-line
, as long as we don't have any brick with the name project
. But because we don't want to get into any name conflicts with bricks and also because each project is executed in isolation, the choice of namespace is less important and here we choose the project.command-line
top namespace to keep it simple.poly
tool and all code can therefore be declared public, which allows us to put the test code wherever we want.info
command:command-line
is marked as changed and flagged as -t-
telling us that it now has a test
directory. The -t-
says that it has been added to the development project. The reason it's not tagged as -tx
is that project tests are not marked to be executed without explicitly telling them to, by passing in :project
.command-line
project is also marked to be tested. Let's verify that by running the tests:poly test
while the project tests are not.info
command again:*
signs are now gone and nothing is marked to be tested.:all-bricks
:development
project. To include dev, also add :dev
:dev
) we can type:development
projects are something we don't normally need to do, but it's good to know that it's supported.command-line
project's test
directory because it's not used by any other project.test-setup
namespace in the project's test directory and add two functions to it:command-line
project in this case). Here the project's own test
directory was already added earlier by the create project
command, so we are fine.workspace.edn
::dev
is not passed in)::dev
:project:proj1
or project:proj1:proj2
. :dev
is a shortcut for project:dev
.brick:b1
or brick:b1:b2
.info
command, as we have done in the examples above, to get a view of which tests will be executed.workspace.edn
, e.g.:info
command with these settings:cli
is included for the command-line
project. This can be useful when we don't want to run the same brick tests from all our projects, as a way to get a faster test suit.:all
../deps.edn
, which gives us access to the tests from the REPL.src
and resources
paths from the REPL, we often add them as :extra-paths
because we want to make sure that the IDE integration will work in all the development environments on the market.Note: At the time of writing, adding bricks todevelopment
using the:local/root
syntax works fine in VSCode/Calva and Emacs/CIDER, but unfortunately not in IDEA/Cursive, see this issue. However, if your organisation doesn't use Cursive, it should be fine to use the:local/root
syntax even for the development project.
./deps.edn
config file sets up all our paths and dependencies, and when we include the dev
and test
aliases (and sometimes profile
aliases, described in the next section) we inform tools.deps what source code and libraries should be accessible from our IDE and REPL. When this is set up correctly, we are also able to run our tests from the REPL, which will have access to all test
and src
code. Libraries that are defined in the src
context will therefore automatically be accessible when running the tests. Additional libraries that are only used from the tests should be defined in the test
context.test
command, the tool will detect which components, bases and projects have been affected since the last stable point in time. Based on this information, it will go through all the affected projects, one at a time, and run the component, base, and project tests that are included in each project. This set of tests will be executed in isolation from its own classloader which will speed up the test execution and make it more reliable. Libraries from both the src
and test
context (and libraries that they depend on) will be used when the tests are executed. If :verbose
is given when running the tests, the libraries and paths that are being used will be printed out. The development project can also be used to run tests, but that's not its main purpose.poly test
command is the sum of all library dependencies that are defined in all the components and bases (either indirectly via local/root
or directly by using :deps
/extra-deps
). If a library is defined more than once in the set of bricks and projects, then the latest version of that library will be used, if not overridden by :override-deps
in the project.:deps
key) which can be libraries like clojure itself, org.clojure/clojure
, that we don't want to repeat in all our bricks.datomic-ions
, we can specify which repository it needs, like this. We can verify that the repo is picked up by the brick by executing poly ws get:components:datomic-ions:maven-repos
:invoicing
project by executing poly ws get:projects:invoicing:maven-repos
:datomic-ions
brick will now also include the datomic-cloud
repository.