Full featured next generation test runner for Clojure.
Project | CI | Docs | Release | Coverage |
---|---|---|---|---|
kaocha | ||||
kaocha-cljs | ||||
kaocha-cucumber | ||||
kaocha-junit-xml | ||||
kaocha-cloverage | ||||
kaocha-boot | ||||
deep-diff |
- to inspect
- to observe and study
- on-the-spot investigation
See the Line Dict entry for an audio sample.
kaocha is part of a growing collection of quality Clojure libraries and tools released on the Lambda Island label. If you are using this project commercially then you are expected to pay it forward by becoming a backer on Open Collective, so that we may continue to enjoy a thriving Clojure ecosystem.
Are you
- reporting a bug? -> File an issue
- looking for support? -> Post to the forum
- looking to contribute? -> Create a pull request or start by discussing your plans on the forum
There is also a #kaocha channel on Clojurians Slack (sign up here), where users can help each other.
- 1. Introduction
- 2. Installing
- 3. Configuration
- 4. Running Kaocha CLI
- 5. Running Kaocha From the REPL
- 6. Focusing and Skipping
- 7. Watch mode
- 8. Plugins
- 9. Extending
- 10. Hooks
clojure.test
assertion extensions- Capability check for org.clojure/tools.cli If a project's dependency
- CLI:
--fail-fast
option - CLI: Print the Kaocha configuration
- CLI:
--profile
option - CLI:
--reporter
option - CLI: Selecting test suites
- Configuration: Bindings
- Focusing based on metadata
- Focusing on specific tests
- Skipping based on metadata
- Skipping test based on ids
- Marking tests as pending
- Plugin: Capture output
- Plugin: Hooks
- Plugin: Notifier (desktop notifications)
- Orchestra (spec instrumentation)
- Plugin: Clojure/Java Version filter
- Automatic spec test check generation
Features include
- Filtering tests based on test names or metadata
- Watch mode: watch the file system for changes and re-run tests
- Pretty, pluggable reporting
- Randomize test order
- Detect when interrupted with ctrl-C and print report
- Fail fast mode: stop at first failure and print report
- Profiling (show slowest tests)
- Dynamic classpath handling
- Tests as data (get test config, test plan, or test results as EDN)
- Extensible test types (clojure.test, Midje, ...)
- Extensible through plugins
- Tool agnostic (Clojure CLI, Leiningen, ...)
This is no replacement for reading the docs, but if you're particularly impatient to try it out, or if you already know Kaocha and need a quick reference how to set up a new project, then this guide is for you.
Add Kaocha as a dependency, preferably under an alias.
;; deps.edn
{:deps { ,,, }
:aliases
{:test {:extra-deps {lambdaisland/kaocha {:mvn/version "1.0.732"}}}}}
Add a binstub called bin/kaocha
mkdir -p bin
echo '#!/usr/bin/env sh' > bin/kaocha
echo 'clojure -A:test -m kaocha.runner "$@"' >> bin/kaocha
chmod +x bin/kaocha
Add a profile and alias
;; project.clj
(defproject my-proj "0.1.0"
:dependencies [,,,]
:profiles {:kaocha {:dependencies [[lambdaisland/kaocha "1.0.732"]]}}
:aliases {"kaocha" ["with-profile" "+kaocha" "run" "-m" "kaocha.runner"]})
Add a binstub called bin/kaocha
mkdir -p bin
echo '#!/usr/bin/env sh' > bin/kaocha
echo 'lein kaocha "$@"' >> bin/kaocha
chmod +x bin/kaocha
In your build.boot
add the Kaocha dependency, and import the Kaocha task
;; build.boot
(set-env! :source-paths #{"src"}
:dependencies '[[lambdaisland/kaocha-boot "..."]])
(require '[kaocha.boot-task :refer [kaocha]])
Add a binstub called bin/kaocha
mkdir -p bin
echo '#!/usr/bin/env sh' > bin/kaocha
echo 'boot kaocha "$@"' >> bin/kaocha
chmod +x bin/kaocha
By default, Kaocha assumes that:
- source files are in the
src/
folder, - test files are in the
test/
folder, - all test namespaces names end with
-test
(e.g.my-project.core-test
). Also, the default test suite id is:unit
(justunit
on the command line).
If your tests don't seem to run (outcome is 0 tests, 0 assertions, 0 failures
)
you may need to write up your own configuration: add a tests.edn
at the root
of the project to configure actual test and source paths, and optionally set a
reporter or load plugins (cf. Configuration in the
documentation).
Example of a catch-all tests.edn
config file (should run all
tests found in src/
and /test
, in any namespace).
#kaocha/v1
{:tests [{:id :unit
:test-paths ["test" "src"]
:ns-patterns [".*"]}]
;; :reporter kaocha.report.progress/report
;; :plugins [:kaocha.plugin/profiling :kaocha.plugin/notifier]
}
Warning: this is not an optimal configuration. To avoid extra churn, you should try and target only folders and namespaces that actually contain tests.
Run your tests
bin/kaocha
# Watch for changes
bin/kaocha --watch
# Exit at first failure
bin/kaocha --fail-fast
# Only run the `unit` suite
bin/kaocha unit
# Only run a single test
bin/kaocha --focus my.app.foo-test/bar-test
# Use an alternative config file
bin/kaocha --config-file tests_ci.edn
# See all available options
bin/kaocha --test-help
- kaocha-noyoda Don't speak like
Yoda, write
(is (= actual expected))
instead of(is (= expected actual))
Kaocha requires Clojure 1.9 or later.
Everyone has a right to submit patches to kaocha, and thus become a contributor.
Contributors MUST
- adhere to the LambdaIsland Clojure Style Guide
- write patches that solve a problem. Start by stating the problem, then supply a minimal solution.
*
- agree to license their contributions as EPL 1.0.
- not break the contract with downstream consumers.
**
- not break the tests.
Contributors SHOULD
- update the CHANGELOG and README.
- add tests for new functionality.
If you submit a pull request that adheres to these rules, then it will almost certainly be merged immediately. However some things may require more consideration. If you add new dependencies, or significantly increase the API surface, then we need to decide if these changes are in line with the project's goals. In this case you can start by writing a pitch, and collecting feedback on it.
*
This goes for features too, a feature needs to solve a problem. State the problem it solves, then supply a minimal solution.
**
As long as this project has not seen a public release (i.e. is not on Clojars)
we may still consider making breaking changes, if there is consensus that the
changes are justified.
Copyright © 2018-2020 Arne Brasseur and contributors
Available under the terms of the Eclipse Public License 1.0, see LICENSE.txt