This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-26
Channels
- # announcements (17)
- # babashka (68)
- # beginners (8)
- # biff (14)
- # calva (25)
- # cherry (10)
- # clj-kondo (1)
- # clj-on-windows (12)
- # cljsrn (6)
- # clojure (134)
- # clojure-berlin (1)
- # clojure-europe (33)
- # clojure-nl (4)
- # clojure-norway (6)
- # clojure-uk (10)
- # clojurescript (9)
- # datalevin (8)
- # datomic (34)
- # docker (1)
- # emacs (31)
- # fulcro (6)
- # honeysql (8)
- # java (7)
- # joyride (14)
- # kaocha (7)
- # malli (11)
- # nbb (4)
- # off-topic (11)
- # pedestal (14)
- # rdf (53)
- # re-frame (6)
- # reagent (39)
- # reitit (2)
- # releases (9)
- # rewrite-clj (14)
- # shadow-cljs (97)
- # specter (1)
- # testing (5)
- # tools-deps (12)
- # vim (4)
- # xtdb (9)
what would be needed for implementing https://github.com/lambdaisland/kaocha/issues/31? I can think of a couple of implementations:
a. in kaocha core:
• kaocha.config
: an optional :kaocha/default-suites
vector of suite-ids, with :replace
meta-merge behaviour. No default supplied here, as we want to default to ‘all’, which is a moving target as i understand it (e.g. https://github.com/lambdaisland/kaocha/blob/c3b4bfb78287988c1bdba8827c0e4369252ca8fd/src/kaocha/runner.clj#L74-L79, which states suites may be added by hooks)
• some other ns (`kaocha.runner`?): if :kaocha/default-suites
is provided and suites
is not provided, add :kaocha.testable/skip
to relevant suites
b. in a plugin, like kaocha.plugin.filter
• Basically the same approach as above, but done during the pre-load
hook of kaocha.plugin.filter
thoughts?
If it can be a plugin it should probably be a plugin, that keeps the code base a bit more tidy. We can enable it by default if we want to make this a general feature.
hello — I have been starting to use kaocha and this issue of assertions which expect a spec failure failing when using kaocha because kaocha binds clojure.spec.alpha/*explain-out*
to expound’s writer https://clojurians.slack.com/archives/CCY2V0U6A/p1625585285021400. this binding happens https://github.com/lambdaisland/kaocha/blob/c3b4bfb78287988c1bdba8827c0e4369252ca8fd/src/kaocha/runner.clj#L149.
I fixed it by using a wrap-run
hook which binds clojure.spec.alpha/*explain-out*
back to clojure.spec.alpha/explain-printer
.
I was surprised to see that using https://github.com/lambdaisland/kaocha/blob/main/doc/config/bindings.md did not work and didn’t understand why.
I was also surprised to see that when using https://cljdoc.org/d/lambdaisland/kaocha/1.71.1119/doc/5-running-kaocha-from-the-repl`s/explain-out*` is *not bound to expound/printer
, and a test which makes an assertion based on the content of a spec message passes when ran from the repl (because the produced message is in the ‘old’ spec format) whilst the same test ran from the CLI fails (because the message is in the expound format).
I’m also a bit disappointed that migrating to kaocha has had this ‘side-effect’ of causing assertions on spec errors to fail. What’s the reasoning for binding s/*explain-out*
at the top?
Some of these choices are lost to the sands of times. When I started building kaocha spec was the hot new thing, and I tried to lean into it heavily, but I found the default output from spec not user friendly at all, so I brought in expound. The main reason it's set there as far as I can remember is to give people good feedback when their config doesn't validate.