←back to thread

Unit tests as documentation

(www.thecoder.cafe)
174 points thunderbong | 1 comments | 17 Oct 24 17:22 UTC | HN request time: 0.207s | source
Show context
lucianbr ◴[17 Oct 24 18:16 UTC] No.41872163[source]▶
One - unit tests explain nothing. They show what the output should be for a given input, but not why, or how you get there. I'm surprised by the nonchalant claim that "unit tests explain code". Am I missing something about the meaning of the english word "explain"?

Two - so any input value outside of those in unit tests is undocumented / unspecified behavior? A documentation can contain an explanation in words, like what relation should hold between the inputs and outputs in all cases. Unit tests by their nature can only enumerate a finite number of cases.

This seems like such an obviously not great idea...

replies(16): >>41872317 #>>41872378 #>>41872470 #>>41872545 #>>41872973 #>>41873690 #>>41873888 #>>41874566 #>>41874890 #>>41874910 #>>41875148 #>>41875681 #>>41875896 #>>41876058 #>>41878172 #>>41879682 #
1. actinium226 ◴[18 Oct 24 14:15 UTC] No.41879682[source]▶
Unit tests show expected input and output of a function.

In code that was written without tests, inputs/outputs end up being surprisingly far more spread out than you might think. One of the function inputs might be a struct with 5 members, but the function itself only uses one of those members 50 lines in. If it's OOP, one of the inputs might be a member variable that's set elsewhere, and same for the outputs.

A unit test shows the reader what information is needed for the function and what it produces, without having to read the full implementation.

Also, when you write it, you end up discovering things like what I mentioned above, and then you end up refactoring it to make more sense.