←back to thread

Unit tests as documentation

(www.thecoder.cafe)
174 points thunderbong | 2 comments | 17 Oct 24 17:22 UTC | HN request time: 0.504s | 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 #
wubrr ◴[17 Oct 24 23:05 UTC] No.41874705[source]▶
> 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.

What do test names have to do with quality? If you want to use it as some sort of name/key, just have a comment/annotation/parameter that succinctly defines that, along with any other metadata you want to add in readable English. Many testing frameworks support this. There's exactly zero benefit toTryToFitTheTestDescriptionIntoItsName.

replies(7): >>41874814 #>>41874867 #>>41875382 #>>41876013 #>>41876871 #>>41876888 #>>41877002 #
1. misja111 ◴[18 Oct 24 07:03 UTC] No.41877002[source]▶
It's funny, you are asking what test names have to do with quality, and you proceed with mentioning a really bad test name, 'toTryToFitTheTestDescriptionIntoItsName', and (correctly) stating that this has zero benefit.

Just like normal code, test methods should indicate what they are doing. This will help you colleague when he's trying to fix the failing test when you're not around. There are other ways of doing that of course which can be fine as well, such as describing the test case with some kind of meta data that the test framework supports.

But the problem that OP is talking about, is that many developers simply don't see the point of putting much effort into making tests readable. They won't give tests a readable name, they won't give it a readable description in metadata either.

replies(1): >>41881233 #
2. wubrr ◴[18 Oct 24 16:55 UTC] No.41881233[source]▶
> It's funny, you are asking what test names have to do with quality, and you proceed with mentioning a really bad test name, 'toTryToFitTheTestDescriptionIntoItsName', and (correctly) stating that this has zero benefit.

Not at all. Those kinds of names are like a de-facto standard for the people that try to push this kind of practice. Obviously the example I used is not related to any real test.

> This will help you colleague when he's trying to fix the failing test when you're not around.

Really? Encoding what a test function does in it's name is your recommendation for helping someone understand what the code is doing? There are far better ways of accomplishing this, especially when it comes to tests.

> There are other ways of doing that of course which can be fine as well

'Can be fine as well'? More like 'far superior in every possible way'.

> But the problem that OP is talking about, is that many developers simply don't see the point of putting much effort into making tests readable.

Not at all, making a test readable and trying to encode what it does into it's name are completely separate things.