Can TDD make you non-agile?

Can TDD make you non-agile? Yes. When it’s done poorly.

Let’s go back to agility: Agility is about being responsive to change.

Unit tests are supposed to provide you with “safety net” when making changes – when implementing new functionalities, changing functionalities, fixing bugs, and refactoring.

But the reality isn’t so utopic. Here are some common symptoms that you’re doing TDD wrong – when you’re coupling tests with implementation:

1. Change is expensive due to HUGE test code base. This means higher development cost for every feature, for every change, for every bug fix – because they all involve both the implementation code AND the test code. This is wasteful!
 
2. Refactoring is expensive due to BRITTLE tests. This means even during refactoring of classes, it forces you to simultaneously change tests! You have to incur double cost for every change caused by refactoring? (updating both implementation code and test code). This is wasteful!

3. Refactoring is UNSAFE due to BRITTLE tests. So how can you then do refactoring safely, when the tests aren’t stable? How can you trust your tests? When you can’t refactor safely, you won’t refactor. And when you don’t refactor, your design stagnates (no more “evolutionary design”) and your code rots.

So what happens then?

You lose agility. Or we may say that you become (gasp!) non-agile. Why? Because you can’t be responsive to changes. Instead of being your friend, the tests become your enemy.

But why does this occur? It occurs due to the fact that the tests are coupled to structure, instead of being coupled to behaviour. Remember what TDD was all about: “Tests should be coupled to the behavior of code and decoupled from the structure of code.” – Kent Beck

I personally this as the BIGGEST issue in the adoption of TDD. In fact, if this problem isn’t solved then automated developer testing is rendering worse than useless – because it causes people to become slower AND also imprisons us in our design choices (i.e. cannot evolve architecture).

To solve it, we firstly need to understand what exactly is the issue here. Let’s take a deep dive to understand how we can drive architecture & implementation through BEHAVIOUR (as it was originally intended to be done). What does it mean to couple to behaviour? How do we achieve it? And how does this fit in with both TDD & Clean Architecture.