←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.435s | 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 #
gus_leonel ◴[18 Oct 24 08:36 UTC] No.41877434[source]▶
Test names should be sentences: https://bitfieldconsulting.com/posts/test-names
replies(4): >>41880087 #>>41880687 #>>41881699 #>>41882785 #
wubrr ◴[18 Oct 24 17:39 UTC] No.41881699[source]▶
Shallow/meh, article. Demonstrates complete lack of familiarity with many popular testing frameworks/approaches, and proposes a subpar solutions for problems that have already been solved in superior ways.

Your test description/documentation should be sentences, but there is absolutely zero reason to try to encode that into the name of your test function. Not to mention this article then suggests using another tool to decode this function name into a proper sentence for reporting... ok now you completely lost the ability to ctrl+f and jump to the function... terrible advice all around.

Why not just use a testing framework that actually supports free-form sentence descriptions/documentation for your tests?

replies(2): >>41882229 #>>41883316 #
bunderbunder ◴[18 Oct 24 18:38 UTC] No.41882229[source]▶
If my unit testing framework supports free-form sentence descriptions, I'll use it. But I won't use that feature as a wedge issue. It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available()`. Other features of the test framework might have a much bigger impact on my developer experience.
replies(1): >>41883449 #
wubrr ◴[18 Oct 24 21:00 UTC] No.41883449[source]▶
Pretty much every major language/framework now supports free-form test names/descriptions, including JUnit, which is referenced in the article ^ (again, highlighting the author's ignorance). Just because something doesn't bother you personally doesn't mean it's a good thing to follow, especially when its clearly inferior to other options.

> It doesn't bother me all that much to have test functions with names like `test_transaction_fails_if_insufficient_funds_are_available()

I mean, that's one example where you have one outcome based on one parameter/state. Expand this to a 2-field outcome based on 3 state conditions/parameters and now you have a 100-character long function name.

replies(1): >>41904621 #
1. bunderbunder ◴[21 Oct 24 14:35 UTC] No.41904621[source]▶
You seem to be focusing on the most obtuse possible way of structuring descriptive test names for rhetorical purposes. I don't know if that's intentional or not, but either way it's not terribly convincing? If you name tests according to business domain concepts rather than tying it to individual parameters through some formulaic rubric, it's often possible to come up with test names that are both more concise and easier to understand than the specific way of naming tests that you've been consistently steering the conversation back toward throughout this thread.
replies(1): >>41973081 #
2. wubrr ◴[28 Oct 24 16:34 UTC] No.41973081[source]▶
> You seem to be focusing on the most obtuse possible way of structuring descriptive test names for rhetorical purposes.

No, I'm focusing on the most realistic and common ways this kind of pattern actually exists (based on my experience).

> If you name tests according to business domain concepts rather than tying it to individual parameters through some formulaic rubric,

While you say I'm focusing on 'the most obtuse possible way...', this kind of comment makes it seem like you haven't focused on any actual way at all. You're speaking in very ambiguous and vague terms, which actually can't be applied and enforced in practice. If you're actually trying to write a suite of unit tests around, say a function, with 3 parameters and multiple possible outcome states - you can't name your function the same for the different combinations of inputs/outputs, and you can't just handwave a 'business domain concepts' name into existence to cover each case - that just turns into an exercise of finding synonyms, abbreviations, and vague generalizations - it doesn't solve the fact that you still need all of the same test cases and they all still need to have unique function names.

You haven't actually thought through what you're proposing here.