09.15.05
That’s not a unit test!
“A test is not a unit test if:
- It talks to the database
- It communicates across the network
- It touches the file system
- It can’t run at the same time as any of your other unit tests
- You have to do special things to your environment (such as editing config files) to run it.”
This really rings true for what I’ve seen lately. Partly it’s a matter of syncing up definitions. I’ve worked at jobs where “unit testing” meant “go test the webapp on all the different browsers.” I call method-level (or object-level) tests unit tests. Lately a lot of people have been calling tests that require a full database, populated with lots of data in a very specific setup unit tests. It just makes me want to scream, “That’s not a unit test!”
That doesn’t mean you shouldn’t write tests that require a network, or a database, or anything in that list, for that matter… I just call those integration tests. They’re no less good, they’re just for a different purpose. In “nirvana land” those are used to ensure that the QA environment is good, that all your code compiled together is good, there are no configuration issues or there are no unintended side-effects, that sort of stuff.
The tricky part is explaining that to people. I get it, I mean, if you haven’t seen “nirvana land” it’s hard to grok it. It’s where you don’t notice the code doesn’t have any comments. It’s where you don’t have to think so hard about every change because you trust your tests to catch it. I miss “nirvana land”.
I have a plan, though.
- Send link to all the developers you know.
- …
- Profit!
Stupid underpants gnomes and their half-baked plans. I need a step 2.
As an odd side-note, you don’t need automated unit tests to be there. My first experience with perfectly readable code was the gtk+ code for one of the early releases of the Gimp post-motif. It’s just that automated unit tests happen to make it a lot easier, therefore it takes less smarts (i.e., drunk programming), less time and just plain less effort.