This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-04
Channels
- # announcements (8)
- # babashka (78)
- # beginners (15)
- # calva (6)
- # cider (12)
- # clerk (1)
- # clojure (46)
- # clojure-dev (13)
- # clojure-europe (15)
- # clojure-norway (5)
- # clojure-portugal (1)
- # clojure-uk (1)
- # clojurescript (23)
- # clr (29)
- # conjure (4)
- # core-async (10)
- # cryogen (1)
- # data-science (8)
- # hoplon (4)
- # hyperfiddle (11)
- # introduce-yourself (3)
- # jobs (6)
- # kaocha (12)
- # lsp (11)
- # malli (8)
- # membrane (11)
- # releases (1)
- # shadow-cljs (20)
- # spacemacs (47)
- # tools-deps (1)
Announcing https://github.com/matthewdowney/rich-comment-tests (,
) 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.
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
Announcing v1.0.0 of https://github.com/matthewdowney/rich-comment-tests (,
). One bugfix and no breaking changes since my last post here, and I'm happy with the API so it is now stable.
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.
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.
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.
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.
Announcing v1.0.0 of https://github.com/matthewdowney/rich-comment-tests (,
). One bugfix and no breaking changes since my last post here, and I'm happy with the API so it is now stable.