In yesterday’s post, the advice was pretty clear: Avoid Unit tests.
They will cause you pain, they will turn your team off to the idea of testing, and you will rue the day you thought unit tests were a good idea.
(Also, as was pointed out to me by very smart people, it’s important to note that this is advice for the developers among us who do *not* write Software libraries. If you write a software library, your library isn’t radically changing; and therefore permanence of a unit test doesn’t have quite the same negative effect that it does in normal code).
That advice seems pretty… harsh, doesn’t it?
But, let’s look at the landscape.
Do you write unit tests as a part of every story you write?
Do you enjoy it?
Do you get value out of it that exceeds the brittleness aspect?
Are you happy when you make a change and the unit tests break even though they shouldn’t?
With few exceptions, I’ve never seen anyone happy about unit testing.
On the other hand, I’ve seen (and experienced) Test Driven Development’s ability to help a developer break down a problem, solve that problem, and help them triangulate their way to a better codebase as a result.
I’ve not yet seen that happen for Unit Tests, writ large.
So what do we do?
The answer is an unsatisfying “it depends”, but I do know the first step.
The first step is to articulate the value you’re trying to get out of unit testing.
If you can write down what you think unit testing buys you, or what you hope it buys you, write that down here.
Go ahead, right now. Hit reply, and in the comments write down what unit testing buys you, what you hope it buys you, and its overall value to your team.
It’s bad to take down a fence before you know why it’s put up in the first place. So let’s dive into why that fence is there.