kaocha

Gosha 2025-02-26T10:02:08.323639Z

Hello! I’m curious how folks go about debugging their tests, and more generally what kind of TDD dev workflows there are. I’ve been running my test suite via the CLI for now, but I’m guessing that for debugging it might make more sense to run them via the REPL? I’m using Doom Emacs and CIDER if it makes any difference. I come from the Ruby/Rails world, where, to debug an rspec test for example you’d just put a breakpoint in it and the test runner would drop into a console — trying to see if I can achieve something similar in Clojure with Kaocha.

Gosha 2025-03-03T09:42:35.835659Z

Oh awesome idea @plexus, thank you!

imre 2025-02-26T10:40:56.926819Z

a normal, repl-based workflow in clojure would be along the lines of: • write test, run it in the repl, see it fail • write code, load into repl, run test in repl again, see it pass • refactor, load into repl, run test again

imre 2025-02-26T10:41:07.873109Z

at least normal to me

Gosha 2025-02-26T10:42:23.714899Z

Thank you @imre! That makes sense. So you rarely if ever run your tests from the command line?

imre 2025-02-26T10:42:53.846839Z

Yeah, I keep that to running the test suite before I push, and CI also runs that

Gosha 2025-02-26T10:44:19.074679Z

Makes sense. And so if you run your tests in the REPL, does it mean that you have kaocha in your base deps (and also include the “test” path in your base paths?) Currently I have kaocha as an extra-deps in my :test/run alias (and also set the additional path there)

imre 2025-02-26T11:10:01.152409Z

I use Cursive with IntelliJ and that includes its own test runner so I mostly just use that to run tests. I also have kaocha part of my test alias and I sometimes call it from the repl

imre 2025-02-26T11:10:16.610329Z

I'm sure Cider has its own test runner command that doesn't need kaocha

Gosha 2025-02-26T11:10:39.255009Z

I’ll investigate. Thank you very much for your help!

practicalli-johnny 2025-02-26T11:25:44.427279Z

For a TDD approach, I do what @imre described above. If I am not familiar with the domain or libraries used in the project then I first do repl experiments in a (comment ,,,) for. Those code experiments may form one or more tests and example data. When working on commercial projects I tend to do all of these (preferably using Koacha) • run a specific test (or specific namespace of tests) I am developing in the REPL • run a command line test runner in watch mode to run all tests on file change (ensures saved source code is tested rather than REPL state) - or do a test run before pushing commit(s) • CI test runner in PR to ensure its not just my machine the tests pass, also used for longer running integration tests I use a deps.edn alias to add the kaocha library to the project and keep it out of the main dependencies, e.g.

:test/env
  {:extra-paths ["test"]
   :extra-deps 
     lambdaisland/kaocha {:mvn/version "1.91.1392"}
     org.clojure/test.check {:mvn/version "1.1.1"}}}
There are more examples of aliases in https://practical.li/clojure/clojure-cli/practicalli-config/

practicalli-johnny 2025-02-26T11:36:48.835519Z

To run Koacha as the Emacs Cider Repl, use https://github.com/magnars/kaocha-runner.el https://practical.li/spacemacs/testing/kaocha-test-runner/, not sure if anyone added it to Emacs Doom

Gosha 2025-02-26T11:49:55.126419Z

@jr0cket Thank you very much, I’ll investigate all that!

plexus 2025-03-03T07:43:07.702379Z

Note that you really don't need any separate runner. Just eval (kaocha.repl/run ,,,). I set these registers in my init.el, and have a binding ,, to eval a register, so I can use ,,k to run kaocha.

;; use with ,,<letter>, e.g. `,,g' runs (user/go)
(set-register ?k "#_clj (do (require 'kaocha.repl) (kaocha.repl/run))")
(set-register ?K "#_clj (do (require 'kaocha.repl) (kaocha.repl/run-all))")

❤️ 1