corenamespace in the
usercomponent by adding an extra
!, that should do the trick:
diffcommand, which will give us this output:
usercomponent is now marked with an asterisk,
*. If we look carefully we will also notice that the status flags
clcolumn now has an
xin its last position. As we already know, this means that the tests for
cliwill be executed from the
command-lineproject if we execute the
climarked to be tested? The reason is that even though
cliitself hasn't changed, it depends on something that has, namely the
developmentproject are all marked as
st-. The reason the
developmentproject is not marked to be tested is that the
developmentproject's tests are not included by default.
interface-testnamespace in the
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:
testcommand will pass too:
developmentproject when we run the
testcommand. But there is a way to do that, and that is to pass in
command-lineproject is marked for test execution.
Note: In version 0.2.13-alpha and earlier,
project:devwas an alias for
:dev, which meant that it behaved the same as passing in
project:devand as a result, it only included development in the test execution.From version 0.2.14-alpha and later, this has changed so that
:devmeans "also include development" without excluding any other projects. Another difference is that
poly test :all project:p1in 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:cl:dev(both project alias and name can be used). If development is given, it will automatically be included as if
:devwas passed in:
poly info project:dev
poly info project:cl:dev
clproject are marked to be tested.
brick:cliparameter is just a filter that is applied after the other status calculations have been performed.
clitests to be executed, we need to pass in
:allif we also want to execute the project tests):
clibrick 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
:allto execute only the project tests.
testdirectory for the
project.command-line.dummy-testnamespace to the
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-linetop namespace to keep it simple.
polytool and all code can therefore be declared public, which allows us to put the test code wherever we want.
command-lineis marked as changed and flagged as
-t-telling us that it now has a
-t-says that it has been added to the development project. The reason it's not tagged as
-txis that project tests are not marked to be executed without explicitly telling them to, by passing in
command-lineproject is also marked to be tested. Let's verify that by running the tests:
poly testwhile the project tests are not.
*signs are now gone and nothing is marked to be tested.
developmentproject. To include dev, also add
dev) we can type:
developmentprojects are something we don't normally need to do, but it's good to know that it's supported.
testdirectory because it's not used by any other project.
test-setupnamespace in the project's test directory and add two functions to it:
command-lineproject in this case). Here the project's own
testdirectory was already added earlier by the
create projectcommand, so we are fine.
:devis not passed in):
:devis a shortcut for
infocommand, as we have done in the examples above, to get a view of which tests will be executed.
infocommand with these settings:
cliis included for the
command-lineproject. 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.
./deps.edn, which gives us access to the tests from the REPL.
resourcespaths from the REPL, we often add them as
:extra-pathsbecause 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 to
:local/rootsyntax 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/rootsyntax even for the development project.
./deps.ednconfig file sets up all our paths and dependencies, and when we include the
testaliases (and sometimes
profilealiases, 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
srccode. Libraries that are defined in the
srccontext will therefore automatically be accessible when running the tests. Additional libraries that are only used from the tests should be defined in the
testcommand, 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
testcontext (and libraries that they depend on) will be used when the tests are executed. If
:verboseis 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 testcommand is the sum of all library dependencies that are defined in all the components and bases (either indirectly via
local/rootor directly by using
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-depsin the project.
:depskey) 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:
invoicingproject by executing
poly ws get:projects:invoicing:maven-repos:
datomic-ionsbrick will now also include the