Fork me on GitHub
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


> 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