I work with many clients on improving their unit testing skills. Most of them approach me with the starting premise of “we don’t write unit tests at all”, or “not enough”.
That may be true, but I usually explain that while unit tests do help in a lot of cases, they may not exactly what will make their life better.
I’m not talking about other types of tests that they should be writing instead, or in addition. I’m talking about the end goal.
We don’t write tests for fun. Well, I do, but I’m probably the exception. If we could write code that works, that we know would work, without writing any tests, wouldn’t that be great?
The problem is, of course, we can’t write code that just works. The proof is in the bug pudding. We need supporting structures. Like tests, and code reviews. The supporting processes and tooling help us move toward code that works.
Is working code the goal? Yes.
And no.
Because next time we release, (either in 2 minutes, 2 days, 2 weeks, or 2 months) we want to get to that point again. We want to make sure that what worked before, still works, and also, that the new stuff is working. Lots of automation here helps, including unit tests.
So is working code over time the goal? Almost.
What happens when your code works, but is an unreadable, pasta-shaped mess? Every time you make changes, you run into the risk of breaking something (which is why a good test suite will save you).
However, while you’re fighting the spaghetti monster, your output cadence will drop. Changes are going to take time, and you’ll break and fix stuff on the way. If before you got ten features within a two week release, soon enough you only get five, then two.
The good news is, if you have tests, you can refactor the code safely, to keep it maintainable and readable. Tests allow you to keep changing the code, without the penalty of delays.
And there’s your goal: Working code. Over time. In a constant speed.
Now, unit tests help us get to that goal. And they may be exectly what you really need. But other automated tests help, too. Clean code helps. Refactoring and design patterns help. And all serve that final goal.
Repeat after me:
Working code. Over time. In a constant speed.
If you’re sure, really positive, that you do need unit tests, check out my Unit Testing workshop. It is a good start.
0 Comments