TDD takes the idea of Automated Testing one step further. Rather than simply having tests, you don’t write any production code until you have a failing test.

The TDD process is a 3 part cycle:

  1. You write a failing test (the feature that’s needed doesn’t exist).
  2. Then, you make it pass (by adding the feature).
  3. Then, you clean up the code with refactoring (as needed).

The main benefit here is you’re making sure the code you write can be tested from the get-go. This forces you to implement some best practices.

In practice, I find that people often do better switching between testing before and writing tests after. Sometimes it’s just easier to think about what code you need to write without also thinking about how you’ll test it.