Member-only story
Why don’t developers use TDD in practice
Like everything that comes under the name of Agile, Test Driven Development (TDD) is something that sounds great in theory. In practice, it is unclear how to do it right. You are often told that if you don’t like it, you are doing it wrong. It comes as no surprise that most developers I’ve met could explain the benefits of using TDD while none of them used it in their work. Not a single one.
Lately, there have been voices against TDD, blaming it not worth the effort and not keeping many of its promises. Some even claim that TDD is dead. How could something so advantageous is so unwelcome to developers?
In this article, I want to talk about four major problems with TDD in practice that explain this phenomenon.
Problem 1: Refactoring breaks many tests
If we make a small change to the implementation code, none of the tests would break. That is one of the promises that TDD makes. In practice, at least a thousand tests break. Something that should not happen happened. To fix that, we often rewrite, not refactor, our test code. We spend a lot more time writing test code than the implementation code.
In the end, we doubt if it is worth rewriting the test code if we are sure we will refactor the implementation code. Can we write fewer tests? Can we skip all the tests? Then, someone will suggest writing tests when all changes are made, like the day before release. In practice, it is often after release, or never.
Problem 2: Writing more test code than implementation code
To test a “unit” of the implementation code, we often write tests for all public methods and write mocks for dependencies. Sometimes we make private methods public because otherwise there is no way to increase our code coverage. We create test cases to cover as many different…
