Opening Paragraph 

One of the biggest failed projects I worked on had unit tests. Or so I thought. I was leading a group of programmers to create a billing application, and we were doing it in a fully test-driven manner – writing the test, then writing the code, seeing the test fail, making the test pass, refactor, rinse, repeat.    

The first few months of the project were great; things were looking up, and we had tests that proved that our code worked. As time went by, requirements changed, and we were forced to change our code to fit those new requirements. Whenever we changed the code, tests broke and we had to fix them – the code was still working, but the tests we wrote were so brittle that any little change in our code broke them, even though the code was working just fine. It became a daunting task to change our code in a class or a method for fear of changing all the unit tests involved with that unit being tested.   

Worse yet, some tests became unusable because the people who wrote them had left the project and no one knew how to maintain the tests, or what they were testing. The names we gave our unit test methods were not clear enough. We had tests relying on other tests.We ended up throwing away most of the tests less than 6 months into the project.    

It was a miserable failure because we let the tests we wrote do more harm than good – they were taking too much time to maintain and understand than they were saving us in the long run. So we stopped using them.I moved on to other projects, where we did a better job writing our unit tests, and even had some great successes using them, saving huge amounts of debugging and integration time.    

Ever since that first project that failed, I’ve been compiling best practices for unit tests and using them on the next project. Every time I get involved in a new project, I find a few more best practices. A solid naming guideline is just one of those. Understanding how to write unit tests, and making them maintainable, readable and trust-worthy is what this book is about– no matter what language or Integrated Development Environment (IDE) you work with.    

This book will cover the basics of writing a unit test, then move on to the basics of Interaction testing, and from then we’ll move to best practices for writing, managing and maintaining unit tests in the real world.

Download the first chapter as PDF 

Comments? Errata?

 Be heard!