Clojurians Log v2

late reply here, I read through that thread and I think it's not particularly generous and conflating a couple things. Kaocha is not limited to clojure.test. It decouples the test runner from the test library (clojure.test), with an abstraction between the two. It is meant to be a general test runner infrastructure that can handle any type of test. But it's essentially a framework, you do have to write stuff to make things work with kaocha. It's set up in a way to be maximally flexible and accomodating for the implementor, but you do need to do that work. If you're implementing a new testing approach, you have a choice, do it all from scratch, or build it as a kaocha test type. I think you get a lot for free when choosing the second, but it does mean your thing now only works with kaocha. I guess the author didn't want to make that choice. Basically kaocha lets you write a new test library without having to write an accompanying runner. And yes that doesn't mean you automatically get assert-expr etc support, because that's clojure.test specific. If you build a new test libary you're not going to get that.

Thanks for taking the time to read through! Question: the kaocha.report namespace is quite specific to clojure.test. What would someone who want to do reporting independently of clojure.test need to do?

It's really not, it just borrows the concept of having events as maps, and having functions that output something based on those events.

wait let me look at how this all works again 🙂

yeah I guess we do rely on clojure.test/do-report as an interface. You need to agree on some mechanism for the test library to emit events. I'll think about this some more, maybe we could come up with a lightweight artifact that just provides the interface with ways to plug in to it on either side (sending events and receiving/handling events) in kaocha the handling events is done by setting reporter functions, the sending events is done through calling clojure.test/do-report

then again clojure.test is always there, so you might as well use that var as your interface, but there are some annoying things about it, so maybe coming up with a new thing would allow us to shed some of that historical baggage

Would love if @nbtheduke could chime in here. I feel like there is a good opportunity to make the kaocha interface more lightweight to better support test types that don't want to use clojure.test at all

From the outside, it seems to me that y'all relied on clojure.test/do-report because that allows for "seamless" useage by people who've written custom assert-exprs and assertion macros that rely on clojure.test/is. i relied on that heavily when (at my last job) i switched our tests from leiningen's built-in test runner to kaocha and didn't have to change any of the custom assertion macros we'd written

this lets folks use Expectations v2 or matcher-combinators with ease and get all of the kaocha features on top, no (or very little) manual fixing work necessary

Yes, that was certainly part of the reasoning. Hard to get people to adopt a new thing if it breaks their existing tools and workflow...

i'm sorry to @plexus that you feel i wasn't generous to kaocha; i would hope that my contributions to kaocha (issues and PRs) would indicate that i am not trying to disparage it

Is it possible to make the reporter polymorphic on the test type?

No worries @nbtheduke I do remember plenty of contributions and positive interactions, I wasn't trying to make this personal!

It saddens me to see that people choose to rebuild stuff from scratch instead of leveraging kaocha, it means I failed at one of the main goals I set out to do... but I understand there's historical baggage there that people want to opt out of. It's also been one of the most painful parts of building kaocha, trying to keep the design clean and functional while still interoperating in a good way with existing stuff.

I think if we want to get beyond that the first step is to get all the people doing test runner or test libraries around the table, and see if we can come up with a generic pluggable interface between runner, assertions, and reporters. And then start the long slow process of getting all the tools to be retrofitted to use that.

Yeah, asserting being bound to reporting really limits what can be done

Opened an issue at https://github.com/lambdaisland/kaocha/issues/466 for future consideration