An interesting observation came up at work the other day, while we were discussing developer working habits.
Say you’re adding a new feature to an application, that takes 2-3 days to develop. If you don’t write any unit tests, you have no way of knowing if any of your code works until you’ve finished everything, and you can start the application and see it live and working (or not). You can’t confidently check in until you’ve finished coding the entire feature.
If you’re doing test-driven development, however, you have lots of little checkpoints along the way. This class works, check it in. Red, green, check it in. You don’t need to wait for the whole feature to be finished before committing, because your tests prove that the individual parts work. You can confidently check in your changes much more frequently, significantly decreasing integration risk, and the chances of ugly merge conflicts.
Just another reason why you should be doing test-driven development!
