Test Driven Development (TDD) is a method used to write code more efficiently by writing tests (a small amount of code that makes sure your code is working properly) first. The benefits of writing tests are huge. When a test fails you will usually get an error pointing out exactly what is wrong and where to find the problem. This can be exploited to make the development process easier.
TDD has three steps, usually referred to as red, green, refactor. When you finish writing a new test it should be run immediately. The test should fail and give an error (the test is “red”). If it passes there’s no reason to write more code for it. After receiving the error, write just enough code to make the test pass (“green”). After the basic function of the code being tested is working, refactor that code. This means going back over the code you just wrote and cleaning it up without altering the way it works. A successful refactor should result in a cleaner, better unit of code that still passes the test.
Doesn’t that sound like a much more efficient way to write code? Before you get started, keep this in mind: you don’t have to test everything. Writing a separate test to ensure variables are the correct type or that all your web pages have appropriate titles is going too far. Having 100% test coverage (the percentage of code being tested) is unnecessary and a waste of time that could be spent continuing development.
A good TDD strategy is having a couple of sanity checks (making sure the really basic stuff is working properly) and good coverage of the core features of your program. Some features that you know definitely work (like a button that has a single very obvious function) don’t need to be tested. Of course, there are times when these rules should be broken and seemingly trivial code tested.
When you do testing by using the program (you do use your own program right?) you’ll inevitably run into edge cases. These are use cases or functions you didn’t anticipate when planning and writing the program. Sometimes edge cases break. When this happens, you’ve discovered a bug in your code. When an edge case is found and it is complex enough to warrant a test or is broken, a test should be written for it. Writing a test after finding a problem ensures it will never happen again. If the code does break again, the test will fail and alert you.
Test Driven Development is a great way to write well designed code. By writing tests first you write code using the code you are going to write. This lets you design the code to be easy to use, since you’re using it before you write it. Testing everything is unnecessary. Tests should be written for core features, bugs, and complex edge cases. When something breaks, write a test and fix it. Using TDD will lead to better code and a more efficient development process.