Test-Driving Code

Long before the practice of TDD the practice of creating software went something like this.

• Write some code.
• Write some more code.
• If you have time write a test for your code.
• If it breaks fix it fast, and push it live.

Developers didn't write test because code usually worked or they used an excuse such as “they had if statements” in the code to check for errors. Other reasons for not testing might be “testing would slow me down” because it would often take less time to fix a bug than to write a comprehensive test for a piece of code.

But what happens if you can't have downtime? What happens if you need to refactor a lot of your code and can't afford to find out where it breaks because you can't have downtime?

For these cases you write a test. The practice of writing test-first was introduced as test-driven development.