Automated testing and test-driven development are not the same

Automated testing is where you write tests to ensure that your code works as expected, which can be re-run as needed and executed automatically without user input.

Test-driven development (TDD) is when you write the tests before the production code. You see the tests fail and write code until they pass, and then repeat the process. However, TDD is not just about the tests - it’s about the design of the code.

By writing the tests first, you guarantee that the code that you write will be testable, which isn’t something that you can’t do if the production code is written first.

You may need to refactor your initial working implementation before it can be tested - which means that you could also break it during that time and need to spend time debugging and fixing any regressions. Ideally, you want the tests in place first before any refactoring, so if something breaks, you’ll know because of the failing test.

TDD keeps your code cleaner and simpler, as you only write enough code to make the tests pass. Once a test is passing, you stop writing code, so you’ll end up with less, simpler code as it’s easy to know when to stop.

If you don’t write the tests first, you may be tempted to skip writing them completely, leaving untested code or adding TODO: add test comments that may never get reviewed.

Also, where’s the fun in writing tests for code that you’ve already written, that you know are going to pass?