Fork me on GitHub
#announcements
<
2023-01-04
>
Matthew Downey22:01:51

Announcing https://github.com/matthewdowney/rich-comment-tests (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 https://github.com/hyperfiddle/rcf/ 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
2
jeroenvandijk09:01:22

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 https://github.com/matthewdowney/rich-comment-tests (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
seancorfield19:01:26

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.

seancorfield00:01:26

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 https://github.com/matthewdowney/rich-comment-tests/blob/main/src/com/mjdowney/rich_comment_tests/test_runner.clj, mostly just using clojure.tools.namespace to find source files, but there's some setup of clojure.test state for test counters and output.

seancorfield19:01:43

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