Writing tests before code: TDD explained simply
No, writing tests before the code isn't a mistake. It's the very principle of test-driven development — and it's a game changer.
1 min read
“Are you sure you’re not getting it wrong?” Someone from the business side once said this to me, a touch condescending, when I explained that in TDD you write the tests before the code. Yet that’s exactly the point.
Know before you code
When you program a function, you need to know what parameters it will receive and what result it should return. If that isn’t clear, you’re not ready to code yet.
TDD — Test Driven Development — means first writing your edge cases, as if you were already using the function, then writing the code so those tests pass. You then re-run the tests as many times as needed until everything turns green.
A safety net for change
This method also lets you refactor with confidence: you optimize the code while being sure the functionality stays intact, because the tests act as a safety net. They become a kind of living documentation you can replay at will as the system evolves.
The result: durable tests, faster development, higher-quality code and fewer defects. The person across from me seemed skeptical. Yet it’s a practice I’ve used, and one that genuinely adds value.