To TDD or not to TDD?

tl;dr: Before asking whether or not to write tests before features, decide whether to write tests at all. There are only two reasons to write a test: to harden code or to eliminate manual testing. Once you’ve decided to write tests, then write them first.

Programming fads come and go, but Test-Driven Development (TDD) is enduring because it’s like eating your vegetables. We all know we should do it, but we really don’t want to.

The pros and cons of TDD are apparent. Tested code is more stable, and writing your tests before features guarantees that tests will be written at all. If you’re faced with a deadline, with a feature finished, but no tests written, politics dictates that the tests will be cut.

The cons are obvious as well, but probably not frequently discussed due to programmer hubris. Writing tests is extra work and often in a domain-specific language and environment that is different from where the features will be written. Context-switching takes cognitive work.

Test glut can also slow code evolution. I have encountered many situations where tests are failing for deprecated features, forcing me to take a sidebar to patch the test, or to have to code around it. Superfluous tests can distract releases.

Back to the original question: To TDD or not to TDD? Like most questions, the answer is…