Running tests
You can run clojure.test
tests pretty quickly in CIDER. Pressing C-c C-t
n or C-c C-t C-n in a source buffer or a REPL buffer will run
the tests for the namespace you're currently in. CIDER is smart enough to figure
out the namespace containing the tests. The inference logic works in a pretty
simple manner - if you're in an implementation namespace (e.g. some.ns
) CIDER
will try to find a matching test namespace (by default some.ns-test
) and run
the tests there. On the other hand - if you're in something that looks like a
test namespace (e.g. some.ns-test
), then the command will simply run the tests
in that namespace. From time to time, however, you might want to suppress the
test namespace inference logic (e.g. you have some tests in the implementation
namespace that were defined with clojure.test/with-test
)
- in such cases you should use C-u C-c C-t C-n, which will simply run
whatever tests are present in the currently visited/active namespace.
You can also press C-c C-t C-s to run a subset of the tests defined in the namespace filtered by test selectors. CIDER will ask you for those test selectors in the minibuffer. If you call this command with a prefix (C-u C-c C-t C-s) you can suppress the inference logic as for run tests for the namespace.
You can also run all loaded tests with C-c C-t l or C-c C-t C-l and all tests within a project with C-c C-t p or C-c C-t C-p (note that this will load all namespaces in your project). If you call these two with a prefix CIDER will ask for test selector filters and only run those tests in the project which match the selector inclusions/exclusions. Using C-c C-t t or C-c C-t C-t, you can execute only the test at point.
Test selectors are originally a leiningen
feature - see lein help test
for some explanation.
People use them to define subsets of tests usually run together for different purposes. For
example you can mark some of your tests with the ^:smoke
metadata marker others with
^:integration
. This enables you to run these tests separately in your build pipeline.
This feature in CIDER helps you to run these test subsets in your development environment.
All test commands are available in REPL buffers as well. There you can also use , to invoke some of the testing commands.
In the buffer displaying the test execution results (*cider-test-results*
)
you'll have a bit of additional functionality at your disposal.
Keyboard shortcut | Description |
---|---|
g | Run test at point. |
n | Run tests for current namespace. |
s | Run tests for current namespace with selector filter. |
l | Run tests for all loaded namespaces. |
p | Run tests for all project namespaces. This loads the additional namespaces. |
f | Re-run test failures/errors. |
M-p | Move point to previous test. |
M-n | Move point to next test. |
t or M-. | Jump to test definition. |
d | Display diff of actual vs expected. |
e | Display test error cause and stacktrace info. |
Certain aspects of the test execution behavior are configurable:
-
If your tests are not following the
some.ns-test
naming convention you can customize the variablecider-test-infer-test-ns
. It should be bound to a function that takes the current namespace and returns the matching test namespace (which may be the same as the current namespace). -
If your individual tests are not defined by
deftest
ordefspec
, CIDER will not recognize them when searching for a test at point incider-test-run-test
. You can customize the variablecider-test-defining-forms
to add additional forms for CIDER to recognize as individual test definitions. -
If you want to view the test report regardless of whether the tests have passed or failed:
(setq cider-test-show-report-on-success t)
Running tests automatically (test-driven development)
CIDER provides a minor-mode that automatically runs all tests for a namespace
whenever you load a file (with C-c C-k). You can toggle it
manually with M-x cider-auto-test-mode
, or you can use:
(cider-auto-test-mode 1)
This is completely equivalent to manually typing C-c C-t C-n every time you load a Clojure buffer. Also, as described above before, CIDER is smart enough to figure out the namespace containing the tests.
Using cider-test with alternative test libraries
The clojure.test
machinery is designed to be pluggable. Any test library
can implement it if so desired, and therefore leverage cider-test
. For
instance, test.check does this, and
cider-test
handles defspec
just like deftest
.
As a test framework author, supporting the built-in clojure.test
machinery
(and hence cider-test
) is pretty straightforward:
- Assoc each test fn as
:test
metadata on some var. These are what get run. - Implement the
clojure.test/report
multimethod to capture the test results.
The test.check
library is a good example here. It was also designed completely
independently of clojure.test
. It just adds compatibility in this
namespace.
clojure-expectations added
support for clojure.test
in version 2.2 and should also work with CIDER.