This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-09-14
Channels
- # ai (3)
- # babashka (45)
- # beginners (81)
- # biff (26)
- # calva (10)
- # cider (5)
- # clj-kondo (55)
- # cljfx (6)
- # clojure (125)
- # clojure-berlin (1)
- # clojure-europe (37)
- # clojure-italy (7)
- # clojure-nl (3)
- # clojure-norway (79)
- # clojure-uk (1)
- # clojurescript (63)
- # clojutre (1)
- # conjure (5)
- # cursive (37)
- # data-science (1)
- # datalevin (4)
- # datomic (28)
- # eastwood (6)
- # fulcro (26)
- # graphql (20)
- # honeysql (6)
- # humbleui (4)
- # jobs-discuss (5)
- # kaocha (1)
- # leiningen (8)
- # missionary (5)
- # nbb (4)
- # observability (3)
- # off-topic (7)
- # pathom (8)
- # podcasts-discuss (1)
- # rewrite-clj (18)
- # ring (6)
- # sci (23)
- # scittle (9)
- # shadow-cljs (49)
- # squint (10)
- # testing (11)
- # xtdb (17)
Is there a convention regarding how to formulate testing
blocks? For example testing "Given X, it Y"
or testing "It does X"
or similar
In my project we have a convention to name deftest
after the function that is being tested. How do you do it?
I actually avoid naming deftest
to a function - this usually (in my experience) leads to a tight coupling between the test and the code itself. I prefer to name my tests over concepts - for example, (deftest handing-users
If you're unit testing a function, a 1:1 mapping (coupling, w/e) can be exactly what one wants. Nothing is more testable than a discrete, pure function! (of course there are other levels of testing: integration, e2e)
seconding @vemv here, I like to have tests for things I can iterate over, e.g. unit tests that test functions, integration tests that tests API endpoints, so 1 "thing" equals 1 deftest. Easy to find the tests for the thing, and easy to check that you have tested every thing.
I actually don't like this 1:1 mapping, honestly. I don't feel comfortable knowing that my app works but my tests are saying that it don't
In this 1:1 mapping, I feel that tests actually slow me down, because now I need to keep the same internal structure and state, which is the exact opposite reason I write tests in the first place (that is, to change almost everything on my app and be confident that it still works)
I think both approaches make sense. When I’m writing a library, I want to make sure its API works, so I write tests for its functions. When I’m writing an app, I might be more prone to stepping back a bit from function level testing (but not always).
I tend to name deftest
for the feature I'm testing or some part of the feature. For example, I often separate happy path tests from unhappy path tests so I'll have at least two deftest
for such things. And when I have a bug to fix, I tend to name the deftest
to match the bug (by issue number, typically).
I'm curious about folks' ratio of production:test code? We have just over 104k lines of production code and just over 26k lines of test code right now.
using tokei, I measure 55k of code, 64k of tests. this is slightly skewed tho, because (due to some poor architectural decisions), we have to spend a lot of lines setting up our tests. sometimes it's 30 lines of set up for 5 lines of assertions 😬
I usually have at most 50% production code, 50% test code. At Chlorine, I see 6k lines of code, and 2.5k lines of test. But Chlorine is also somewhat a special case, because it have ZERO "unit tests" because of the nature of the project (unit tests don't help at all, so most of the tests actually connect a REPL and do stuff)