Arne Brasseur

cc @WhittlesJr

I have to say I still haven't really used this functionality and am only superficially familiar with the implementation... > Wouldn't it make more sense to use the existing filtering...

Yes, to elaborate a bit more, clojure.test based expectations should work out of the box. If it doesn't or behaves weirdly then please file an issue and we can look...

Reporters are documented here: https://cljdoc.org/d/lambdaisland/kaocha/0.0-413/doc/3-configuration#reporters If that list is incomplete or inaccurate then a PR would very much be appreciated. `--list-reporters` seems like it would be useful, but not sure...

Here's the [permalink to the slack conversation](https://clojurians-log.clojureverse.org/kaocha/2020-10-29/1603964458.024800) I think making this an opt-in, configurable feature is not a bad idea. This would require changes in the [output capturing plugin](https://github.com/lambdaisland/kaocha/blob/master/src/kaocha/plugin/capture_output.clj) and...

Good point. IIRC there are two aspects to this, one is dealing with matcher-combinator specific events. I believe this is actually no longer necessary since newer versions no longer emit...

Filters form a logical "or". Combining them will match any test that matches any of the filters.

In short, no. Implementing "AND" behavior would actually be easier than implementing OR, I went with the current behavior to allow `--focus my.first.ns --focus my.second.ns` and have them both run....

Hey @kennyjwilli, nice to see you here :wave: I think there's merit to the idea, even though it's a fairly niche use case, and relying on ordering is still somewhat...

You're looking for `kaocha.report/result`