Clojurians Log v2

I actually experimented with building this within kaocha, as kaocha is very nice, but it's still tied to the clojure.test running and reporting structure, so that limits a lot of stuff

https://github.com/lambdaisland/kaocha/blob/main/src/kaocha/report.clj

the namespace docstring goes into a lot of detail about the limitations of clojure.test's reporting architecture

i really wanted the ability to focus on nested contexts and kaocha fundamentally cannot provide that. (i switched a project I have with over 79k lines of tests from using nested testing blocks to only top-level deftest forms (thanks #rewrite-clj!) because it was hard to debug 200 line tests without commenting out 3/4 of it.)

so with those two limitations in mind, i stopped working on my kaocha plugin/extension, and then came across lazytest when reading old sandra sierra articles, and now here we are lol

This is interesting, thank you. I'm wondering if the report-clojure.test coupling is just an oversight or a conscious decision (not looking to support testables other than clojure.test) on Kaocha's end. Also, on "focus on nested contexts and kaocha fundamentally cannot provide that" - is there a short reason for that? AFAIK Kaocha supports nested testables

kaocha's goal is to be a seamless clojure.test runner and reporter. it is built such that one could write their own deftest and testing and is forms and add them in, but then you'd be rewriting most of the existing code anyway and there'd be very little overlap

i sometimes wonder if that would have been better? it's hard to say. building on sandra's base in Lazytest allowed me to do a lot of things that would have been hard or impossible if i'd continued working through kaocha

> Kaocha has a modular architecture. It understands different types of tests: clojure.test, ClojureScript, Cucumber, Fudje, Expectations, so that all of a project's tests can be handled in the same way, and so that more can be added without requiring changes to the core. from https://cljdoc.org/d/lambdaisland/kaocha/1.91.1392/doc/1-introduction

https://github.com/lambdaisland/kaocha-cucumber/blob/main/src/kaocha/type/cucumber.clj is how they implement cucumber tests

they define a way to load cucumber tests, a way to run cucumber tests, and a way to run cucumber features (i don't know what that is). at each step, they're relying on clojure.test's reporting system, and they're using kaocha's runner system (for example, https://github.com/lambdaisland/kaocha/blob/main/src/kaocha/type/var.clj) which you can see is also relying directly on clojure.test

so if i were to write a plugin for kaocha to do "BDD-style" tests, i'd need to write all the stuff i already wrote for lazytest but within the bounds of kaocha: test definitions, assertions, custom runner for the various "types", all new custom reporters that mirror but aren't related to the existing kaocha reporters, and then i'd have to explain that while this is a kaocha plugin, you can't reuse any of the existing clojure.test stuff with it such as assert-expr or what have you

i'd be building a little exclusive universe inside of kaocha, reusing the tests.edn and load/set-up code, but otherwise creating a parallel code base

This is the same problem with Polylith's built-in test runner and Cognitect's test-runner project BTW. I've addressed this in my external test runner for Polylith: it will run both clojure.test and LazyTest tests (if LazyTest is on the classpath). I also have a PR into Cognitect's test-runner to abstract the run/report machinery to some degree, so that it can run either clojure.test or LazyTest or both -- with an additional library providing the LazyTest implementation (for now -- if that PR ever gets merged, my library could be merged into LazyTest to make things more automated).

It's also the problem with CIDER, essentially, which VS Code's (Calva's) test run/reporting is built on. CIDER only knows about clojure.test and only knows how that reports pass/fail etc.

I'm currently thinking maybe some monkey-patching to globally redefine certain clojure.test run* functions might work, and then hook LazyTest's reporting back into clojure.test's machinery.

i need to read up on how CIDER works

Thanks for sharing those details @nbtheduke. Going to ask in #kaocha if there are any future plans to decouple more from clojure.test, looks like at least in this case that property hinders adoption.