We’ve all heard the mantra – Unit Testing is good for the soul. We hear about the goodness of things like JUnit, NUnit, and TDD from other people.
But you’re not convinced.
After all, it takes more time to write unit test code – and you’d rather get on with the next feature. Besides, whether it’s true or not, you certainly feel like your progress is measured by how many features you crank out.
In my own journey, I found I went through three distinct stages to testing heaven. Look at my “diary” for the first few unit tested projects I was on.
Stage 1: "I believe, it's stupid but I believe"
Unit Testing, huh? Great, now I have to spend time writing these stupid tests before I can say I’m done. It’s not really hard, but it takes additional time to create these tests. Time that I think would be better spent moving the project along with more features. I was told to do it, so I will, but I don't see or feel the benefit yet. I write tests because I have to.
Stage 2: OK, it’s good for the project
Hmm, I added a new feature today – and someone else’s test broke. As I checked it out, I found that indeed, I had modified some code that no longer worked for another scenario. So, for the first time I saw a benefit from the tests. Of course, I still think my time is better spent adding new features – but I begin to see that they’re a good thing to have, especially if other people write them. So now I’m voluntarily writing tests for some of the new code I write. The project is better for it.
Stage 3: Hey, I can code faster
And gradually it happened. Bit by bit the the second level effects of testing crept into my work.
- I can write a small test to reproduce a bug, and I don’t need to get a whole test environment set up. This lets me debug my solution much much faster.
- I can write a small test to exercise some code that I can’t even get to from the main application yet. This is cool, because I can implement a feature before someone else needs it. And put it through its paces.
- Now that I’ve gotten the hang of writing tests, I find it extremely easy to write lots of test cases for the same piece of functionality. After writing the first test, it’s real easy to tweak it for many test cases. We always talked about testing all the edge cases – now I can actually do so.
- I can modify code (like redesign the innards of a class) with high confidence that I won’t break something that depends on it – because I have a set of tests to make sure I don’t break behavior. This is where Unit Testing plus Refactoring have a real synergy. The two combined offer a great advantage over either practice by itself. Better quality code that’s easier to maintain.
So that’s how it finally happened. I actively use tests to develop and debug code. In fact – TDD (writing the tests first) as a process kind of snuck up on me. I can’t imagine writing code without tests anymore.
So if you’re not there yet – don’t worry. Especially if your boss is on your case. It’ll come. And when it does, you’ll wonder how you ever ever did without it.