A good saying in software development is that “if it’s not tested it doesn’t work”. Every programmer agrees it’s a good idea to test your code, the question is what’s the best methodology to do the testing. One very useful tool is unit tests, which is code that performs a series of specific tests on a module to test its functionality. By using a common unit testing framework across a project, it’s easy to create new tests, run the entire suite of tests for a project, and check if any tests are failing. Unit tests are great for verifying new code works, and also that a new code change hasn’t broken any previously working code. Kent Beck was an early advocate of unit testing, and helped create the jUnit testing framework.
Test Driven Development flips the idea of unit testing on its head. It advocates writing unit tests before writing the code that gets tested. This way, the tests are actually used to guide the design process. The book goes through several examples of how to apply this methodology, including using Test Driven Development to create a unit testing frame work, which results in a very interesting development cycle. Overall I found the writing and example code quite clear. Kent Beck did well in emphasizing the benefits of TDD:
- By writing unit tests before the actual code, you ensure that your code will have unit tests!
- Unit tests help make the final code more modular and usable, since the tests give the developer a taste of how each class will be used before he even writes them.
- You split the programming work up into very tiny increments, and this increases the momentum.
I read Test Driven Development in 2010, well after it was first published and this development methodology had been introduced to the world. It seems like since this was first release, the mainstream users of TDD have backed off a bit from literally starting any software development by writing unit tests. For large project, I think it’s more practical to do some up front design work. However, I have found that using TDD is great for working on smaller scale projects and modules. It’s also really helpful when you’re dealing with a new language or library, since you get to learn really quickly what works and what doesn’t. Shortly after reading this book I began work on a new feature at my job which used a lot of graph algorithms. I decided to represent the graphs using the notoriously difficult (but efficient) Boost Graph library, and TDD made the learning process go a whole lot smoother.