Fork me on GitHub
#hyperfiddle
<
2021-12-18
>
Drew Verlee06:12:11

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.

Dustin Getz14:12:49

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

sheluchin17:12:18

> 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.

Dustin Getz18:12:32

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

Dustin Getz18:12:47

Postgres for example has 10x more tests than actual code, iirc