March 2, 2012 Yesterday on Twitter, Johan Normén drew my attention to a naming pattern for tests (which he quickly published a blog post about, and where most credit should apparently go to Patrik Löwendahl) that I found quite interesting. It was being compared to the naming convention that has previously been suggested by Roy Osherove (MethodName_StateUnderTest_ExpectedBehavior). The two naming conventions view the system under test from slightly different angles. While Roy's convention is "method based", this other convention can be said to be more "scenario based".
As a side effect, this also sparked a little discussion regarding the definition of a unit test. And it made me think a little bit. Is this urge to have a definition interesting? Does it add value? The intended value is probably that it can shorten communication a bit. I can say "unit test", and people I talk to will immediately know what I mean, have the same image of tests with a certain scope and level of isolation.
But that's not how we function, is it?
We can see this pattern all around, not only when discussing technicalities in code. Marco Arment posted an article a couple of days ago called "Right versus pragmatic", which highlighted how we often try to force "the right" way to do things on people, instead of observing how they actually behave.
I often feel that definitions like "unit tests" do the same thing. It doesn't matter if somewhere there is a definition saying that "a bucket can be labeled unit test only if it is not more than 50% full". No matter how hard we try, different people will still fill different amounts of water into the bucket and stick a "unit test" label on it.
Instead, I like to use a more pragmatic approach. The water in your bucket should not need any external connections. That's a good test. If you want to call it a "unit test", feel free to do so. The only thing I am interested in, is "is this test well-designed?". Sticking a label to it will not make it better or worse. It could, if all people could agree on one definition. In that case, this definition could contain characteristics for well-designed tests. But there will be no such agreement, because we are people. That's what we do. We absorb information, we apply our own experiences and preferences to it, and then we use it. What comes out will be different for different people.
A definition is supposed to make communication simpler, faster, shorter and more clear. Instead I often see how it creates discussion about the definition itself. Instead of helping us focus more on the challenge at hand, the definition becomes a challenge in itself.
So these definitions, do they not fill any purpose at all? Well, I think they do, but not they purpose the seem intended to fill. Instead of facilitate communication, I think that they facilitate thinking. They make us discuss, which forces us to think. Discussion and thinking creates and shares knowledge, and that adds value. But when I need things done, that’s not where they help me.