I use unit tests partly to verify that something works in the first place

November 24, 2019

A long while ago I read Mostly avoid unit tests (via), in which the author starts out with:

Most of the value of a unit test comes when you change the original (tested) code, but not the test, and can run the test to make sure that all is still well. [...]

This is, broadly, not my experience with a lot of the unit tests that I write. A lot of the time I write tests in large part to verify that the code is correct in the first place, not that it's still correct after I change it; in fact, I may never change the code I'm testing after I write it and verify that it works (ie, that it passes all of my tests). Unit tests are often the easiest way to verify that my code is really working, especially if I want to make sure that corner cases work too, errors are handled correctly, and so on.

Not all code needs this or can be easily tested this way (for example if it interacts with the outside world in complex ways), and it very much helps if you test from inside your modules, not outside of them (often you can only directly reach the complex and potentially incorrect code from inside the module). How much I want unit tests also depends on the language I'm writing in. Languages that offer me a REPL give me a way of exploring whether or not my code works without needing to formalize it as written down tests, so in practice I write fewer tests in them.

(Also, after a certain point it's easier to test if some piece of code works by just running the program and exercising it than it is by writing more tests.)

Even when I could explore whether or not my code works through a REPL or through some ad-hoc scaffolding to run it directly, there's a certain amount of value in writing down a table or group of tests. Writing things down encourages me to more fully check the code's range of inputs and possible problems. It's certainly easier to scan a table to see that I haven't considered some case than it is to think back over checks I've already done by hand and realize that I left something out or that I'm not really checking what I thought I was.

(Much of this is probably obvious, and perhaps there are other ways to do it or these are not really proper unit tests. The modern testing terminology sometimes confuses me.)

Written on 24 November 2019.
« Timing durations better in Python (most of the time)
In Prometheus, don't be afraid of high cardinality metrics if they're valuable enough »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Nov 24 23:52:23 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.