Fork me on GitHub
Matthew Downey22:01:51

Announcing (clojure, babashka) for turning normal Clojure comment forms into tests, for both running at the REPL during development and combining with clojure.test workflows / CI. Essentially a less featureful version of the excellent library which uses rewrite-clj instead of macros to enable syntax much closer to "normal" rich comments. I am using it in several personal projects and I believe it is stable as of this version (v0.0.4), but I'm hoping to collect feedback and fix any bugs which might be lurking before releasing a v1.

🎉 48
👏 10
👀 8

Nice! I like the idea of annotating comment blocks and not introducing any runtime dependencies! Personally I believe the ;=> annotation is a bit fragile similar to the midje notation. And i believe emacs paredit does not always know how to deal with a line comment as the last form in a block. Because of this I'm experimenting with a custom macro (=> a b) myself

Matthew Downey18:01:35

Announcing v1.0.0 of (clojure, babashka). One bugfix and no breaking changes since my last post here, and I'm happy with the API so it is now stable.

🎉 20

Looking forward to trying this out at work (now that I'm back from vacation, I've created a JIRA ticket to track our experiment with it). I was originally excited about RCF (from HyperFiddle) but there were several problematic aspects to it -- per various issues in their repo that I discussed with them -- and your approach seems to be both simpler and also side-step those issues.

👍 2
Matthew Downey14:01:29

Oh very cool @U04V70XH6, let me know if you end up with any feedback or if there's any missing functionality you were hoping would be there.


Tried it out today. Very nice! I'll have to give the clojure.test integration some thought -- we have a Polylith monorepo so we have 150+ src folders so the test-runner with :dirs probably isn't going to work for us, but we do generate a test stub for every src file so having explicit tests that use run-ns-tests! for source files known to contain :rct/test forms might be more practical, or I could add an explicit "brick"-level test with the test-runner and the specific brick's src folder as we start to add more :rct/test forms.

Matthew Downey01:01:58

Makes sense! Let me know if there are parts of the test runner I can expose that would make this easier. Right now it's pretty, mostly just using to find source files, but there's some setup of clojure.test state for test counters and output.


I think we're going to settle on having an explicit component-level test for each of the components/<name>/src trees as we add RCTs to each component. If that proves to be too slow/annoying, we may switch to having a specific deftest in each *-test ns just for the matching source ns (since we have test stubs for every since source ns). I updated my VS Code/Calva config to add a custom REPL snippet to run RCTs in the current ns.

👍 2