English | EN 
I think Test Driven Development (TDD) is incredible since it guides the way I develop software. But I understand if other developers are suspicious. Implementing TDD requires investing a lot of time, which is scary without knowing if the benefits are real or just hype.
Ten facts about details
- You are reading this line now
2. But you didn’t notice “line” was written twice.
3. You went back to check it, but were confused,
5. Because “line” wasn’t written twice.
6. But now you didn’t notice, that 4. was skipped.
8. You went back to to check it.
9. You are smiling, because you fell for it
10. And by smiling you didn’t notice that “to” was written twice in 8.
11. or that 7. was skipped.
12. or that “ten facts have become 11 (because we skipped 2)
13. Now you smile again.
I am blind to the details, and so are you – this is why we need TDD for coding software.
But what is TDD?
TDD is about writing a unit test, before writing any program code.
Yes, my unit test will fail without any program code, but that’s perfectly fine.
I will make the unit test pass, when I start on my code.
When my code has passed the unit test, I start writing another unit test.
In this way, I will alter between writing unit tests and write production code.
I agree that it is much easier and quicker to start coding without TDD.
But it is also slower and more difficult to end coding, without TDD – especially for enterprise software.
The first version of my code
I know that without TDD I would try my code out and see if it executes as I expect. If not, then I will fine tune and rewrite my code until it gives me the result I expect.
But if I try my code anyway, why not write it down as a unit test?
TDD helps me verify my code
I won’t have to remember what results to expect or remember how to test the code, whenever I need to fix a bug, optimize the code, clean it or add a feature.
How many times haven’t you thought: “I need to clean this code,” but shortly after you don’t bother because you are afraid of the consequences your change might implicate.
With TDD I can change a variable name, and it will be easy for me to verify if everything still works as expected.
TDD guides me the way I design and code my software
The best part of TDD is that I can more easily experiment with multiple designs. I need only to update my unit tests, and they will guide me, where my code fails. TDD will split the design from the code, so I can focus on my code or design, and not both simultaneously.
Applying changes directly into the code seems faster, but it is not. Developers will lose their focus and waste a lot of time with debugging . This is exemplified in “Ten facts about details”.
Also, bugs found in production will no longer be a force of havoc, but a source that improves my design. Each bug will get its own unit test (or more) to proactively prevent this bug (and probably other bugs) in the future. TDD will make my code become anti-fragile.
TDD guides me the way I write documentation
Documentation needs to be short, accurate, understandable and up to date. But we all know, what often happens when it becomes:
- Short – but also fluffy and cryptic.
- Accurate – but too long to read or understand.
- Understandable – but to long and therefore rarely or never updated.
I use all of my unit tests as thorough low-level documentation, which makes my documentation become:
- Short – I only have a minimum amount of unit tests.
- Accurate and Understandable – I love functioning code examples that I can copy-paste, instead of cryptic and abstract theory-crafting.
- Up to date, whenever a unit test fails, I will have to fix the error in my code or in my unit test, before I will be able to commit my changes.
To sum it up
Yes, implementing TDD requires time and effort, but the benefits are not illusionary.
TDD did not only Increase my productivity and delivery quality.
It continuously improves the productivity and delivery quality of my team.
