This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-12-18
Channels
- # adventofcode (20)
- # aleph (25)
- # announcements (4)
- # babashka (117)
- # beginners (150)
- # calva (4)
- # cider (9)
- # clj-on-windows (2)
- # clojure (9)
- # clojure-europe (4)
- # clojure-italy (3)
- # clojuredesign-podcast (18)
- # clojurescript (16)
- # conjure (1)
- # core-async (35)
- # cursive (13)
- # datalevin (6)
- # datomic (6)
- # fulcro (8)
- # hyperfiddle (5)
- # malli (8)
- # nextjournal (4)
- # off-topic (51)
- # pathom (4)
- # reagent (21)
- # sci (14)
- # shadow-cljs (22)
- # specter (3)
- # testing (22)
- # tools-deps (8)
- # xtdb (7)
I fee like putting the tests on the lines under the function declaration is better unless your pulling in a lot of extra libs into the namespace just for testing in addition to rfc (or whatever). I feel like a new namespace warrants some idea that is greater then the function under test, more specifically, a bunch of new requires and maybe libs specific to a testing context.
Some of our tests require datascript or datomic scaffolding but without wanting to have a namespace dependency on the test database – this can be done by just assuming the global is loaded in test forms due to side effect in the test or dev entrypoint. Because test forms erase in prod
> can you say more about the mess you are seeing?
Maybe it's a side-effect of being a bit new to clj in general, which leads me to try quite a few forms in my REPL just to make sure I've got it right. I've been "growing functions" this way with the help of tests
, but then I end up deleting most of it when I feel the function is ready. The process itself is useful, but if I left all the code in there, it would be quite a bit.
Plus I think that putting all of the tests
in a ns dedicated to testing the way it's usually done with traditional tests kinda takes away some of the intended benefit of RFC - reducing the burden of structure/organizing and distance between implementation and test. So there's a bit of a clash of ideas here for me.
@dustingetz your advice about keeping core tests nice and close and moving regressions and dependent tests to their own test ns sounds like a practical pointer. Thanks.
There is a spectrum or ladder of software maturity, something like paper sketch -> repl -> prototype -> mvp -> product -> qa -> growth -> scale As your app gets bigger portions of your codebase will outgrow RCF, but clojure.test is waiting for you
Postgres for example has 10x more tests than actual code, iirc