←back to thread

Unit tests as documentation

(www.thecoder.cafe)
174 points thunderbong | 3 comments | 17 Oct 24 17:22 UTC | HN request time: 0.635s | source
Show context
bunderbunder ◴[17 Oct 24 22:32 UTC] No.41874483[source]▶
I share this ideal, but also have to gripe that "descriptive test name" is where this falls apart, every single time.

Getting all your teammates to quit giving all their tests names like "testTheThing" is darn near impossible. It's socially painful to be the one constantly nagging people about names, but it really does take constant nagging to keep the quality high. As soon as the nagging stops, someone invariably starts cutting corners on the test names, and after that everyone who isn't a pedantic weenie about these things will start to follow suit.

Which is honestly the sensible, well-adjusted decision. I'm the pedantic weenie on my team, and even I have to agree that I'd rather my team have a frustrating test suite than frustrating social dynamics.

Personally - and this absolutely echoes the article's last point - I've been increasingly moving toward Donald Knuth's literate style of programming. It helps me organize my thoughts even better than TDD does, and it's earned me far more compliments about the readability of my code than a squeaky-clean test suite ever does. So much so that I'm beginning to hold hope that if you can build enough team mass around working that way it might even develop into a stable equilibrium point as people start to see how it really does make the job more enjoyable.

replies(20): >>41874655 #>>41874662 #>>41874705 #>>41875392 #>>41875790 #>>41875904 #>>41875926 #>>41876835 #>>41876977 #>>41877265 #>>41877415 #>>41877434 #>>41877459 #>>41877538 #>>41878062 #>>41878426 #>>41878897 #>>41879455 #>>41879817 #>>41880385 #
ojkelly ◴[18 Oct 24 08:33 UTC] No.41877415[source]▶
Test names are one of those things that are painful because it’s obvious to you as you write it, but there’s an extra hassle to switch gears in your head to describe what the contents of the test is doing.

It is really valuable when they are named well.

I’ve found this is where LLM can be quite useful, they’re pretty good at summarising.

Someday soon I think we’ll see a language server that checks if comments still match what they’re documenting. The same for tests being named accurately.

replies(1): >>41877822 #
1. pydry ◴[18 Oct 24 09:58 UTC] No.41877822[source]▶
I've never seen this as a problem. If you're doing TDD and you have a scenario in mind, you describe that scenario in the name of the test.

If you're writing the test after then yeah, maybe it's hard, but that's one of the many reasons why it's probably better to write the test before and align it with the actual feature or bugfix you're intending to implement.

replies(1): >>41881022 #
2. mewpmewp2 ◴[18 Oct 24 16:35 UTC] No.41881022[source]▶
Maybe also why TDD is hard for me because I only truly start to think or visualize when I'm writing the actual code. I don't know if it's ADHD or what it is, but writing requirements, tests before hand, is just not my forte. It's like I only get dopamine from when I build something and everything else feels frustrating.
replies(1): >>41882618 #
3. crazygringo ◴[18 Oct 24 19:25 UTC] No.41882618[source]▶
I used to be like that sometimes. Then I started realizing I'd get the function 90% complete and discover an edge case and have to start over in a way that could handle the edge case. Sometimes this could happen twice.

Documenting your requirements by writing the tests in advance is of course painful because it forces you to think more upfront about the edge cases in advance. But that's precisely why it saves time in the long run, because then it makes it a lot more likely you can write the function correctly from the start.