The Cost of Testing or You don’t Know what You are Missing

Twice this week people challenged my belief in automated testing and Test Driven Development. The argument that was brought forward was simply: Unit tests are too expensive.

I actually believe the opposite is true. Let me tell you about a little dialog that happened in my development team after two developer where working on a feature for about an hour or two.

First Developer: “I think we got everything. Lets start the application and see if it works.” (starts the application)

Second Developer: “Hmm, doesn’t work.”

First: “Oh, I know, we forget to actually invoke the new feature” (fixes that and restarts the application)

Second: “Looks great. It works. Lets commit it to SVN”

What’s so special about this? They didn’t start the application a single time during the development process for over an hour. Can you do that without writing tests? Of course you can and you will spend restarting the application during the rest of the day until you fixed all the bugs. How long does your application need to restart? Including the time you need to navigate to the state where you can test your application. How long does that take?

Not having to do that. Or at least not very often is a huge time saver. And it’s not only the direct cost of restarting the application. Waiting for the application is often an interruption of your concentration. Do you really think about the next aspect of the feature to implement? Or do you check mail? Get a coffee? In my experience going Test Driven in Pairs is a way more concentrated type of working.

And that is not even considering that your tests will run over and over again, making sure later changes don’t break anything. This alone saved my butt a couple of times.

If you reached that level of TDD it will save money for you and your team. I promise.

But I’ll admit, I didn’t believed that a couple of years ago. I was using tests only when implementing rather abstract stuff. And I thought it wouldn’t be possible to efficiently automate tests for most of the code we wrote. I had to learn a lot. Testing isn’t easy. Most of the code we produce isn’t fizz buzz, but is concerned with GUIs and databases, both make testing hard and expensive. But these problems can be solved, so you can gain the benefit of TDD even for these cases.

And as a side effect you will have to come up with a really nice and clean design of your code in order to test it. This in itself will make future changes more easy and cheap.

Therefore I urge you: Start learning how to test today. If you don’t you will never know what you are missing.

And if promises don’t motivate you: I’m convinced that in a couple of years from now the places where you can just puke code into your IDE will get rare. So if you still have a couple of years to cover until retirement: Beef up your testing skills. It’s one of the best investments you can make in your own future as a software developer.

Great post, but I’d like to know what you’re current approach for testing GUI logic is. I’m a big TDD believer, but have seen that in an Agile project, the changes in the UI are significant and found that my TDD tests are not paying off enough. I’m actually considering ATDD for the UI logic and TDD for all other parts of the system.

“Most of the code we produce isn’t fizz buzz, but is concerned with GUIs and databases, both make testing hard and expensive. But these problems can be solved, so you can gain the benefit of TDD even for these cases.”