kaocha
test-runner
| kaocha | test-runner | |
|---|---|---|
| 4 | 3 | |
| 778 | 276 | |
| 0.1% | 1.1% | |
| 7.4 | 0.0 | |
| about 1 month ago | about 2 months ago | |
| Clojure | Clojure | |
| Eclipse Public License 1.0 | Eclipse Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kaocha
- A History of Clojure (2020) [pdf]
-
Clojure is a product design tool
Full-featured test runner: https://github.com/lambdaisland/kaocha
If you install neil (https://github.com/babashka/neil), you can do `neil add test` which will automatically set up cognitect-labs/test-runner in your project. Then you can run tests with `neil test` (just an alias, you don't have to use it).
> I used Kit to bootstrap this project and the way it set up tests doesn't even work, but this was what most people recommended to me for starting a Clojure project
I don't really like the approach that Kit takes and prefer something more opinionated like Biff. I'd love to hear your feedback if you do end up trying out Biff.
-
Application project template
run tests using kaocha.
-
How can I test my clojure code without re-jacking in every time?
But you can use other test runners, such as https://github.com/lambdaisland/kaocha
test-runner
-
Clojure is a product design tool
> I had to Grok Integrant again because I wouldn't understand my project otherwise.
You can use plain functions and `reduce` for system composition if you want. Take a look at how Biff does it: https://biffweb.com/p/thinking-about-system-composition/
DI should be used sparingly for the top-level, stateful pieces of your system. If you can't understand your program without it, is this a problem with Clojure itself or the design of the program?
> And when it comes to best practices around unit testing, it's another one of those things where no one in the community seems to be sharing much about it.
The `clojure.test` API has stayed the same for the last decade and that's what you'll see in most projects. Is the concern about how to run tests? Both of the following libraries work well:
Minimal test runner: https://github.com/cognitect-labs/test-runner
-
Build and run Clojure projects. CLI, tools.deps and deps.edn guide
:aliases {:test {:extra-paths ["test"] :extra-deps {io.github.cognitect-labs/test-runner {:git/url "https://github.com/cognitect-labs/test-runner.git" :git/sha "8c3f22363d63715de4087b038d79ae0de36a3263"}} :main-opts ["-m" "cognitect.test-runner"] :exec-fn cognitect.test-runner.api/test}}
-
How can I test my clojure code without re-jacking in every time?
Cognitect's test-runner is probably the most commonly used approach with deps.edn and the CLI: https://github.com/cognitect-labs/test-runner
What are some alternatives?
maelstrom - A workbench for writing toy implementations of distributed systems.
rlwrap - A readline wrapper
test-refresh - Refreshes and reruns clojure.tests in your project.
pomegranate - A sane Clojure API for Maven Artifact Resolver + dynamic runtime modification of the classpath
deps-new - A new, simpler alternative to clj-new
timbre - Pure Clojure/Script logging library
rain - 🌧️ A Clojure/Script library for fast and flexible web apps.
apptemplate - Application project template for Clojure
clj-new - Generate new projects based on clj, Boot, or Leiningen Templates!
ghostwheel - Hassle-free inline clojure.spec with semi-automatic generative testing and side effect detection
imba - 🐤 The friendly full-stack language