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)