Without TDD, your KEY DEVELOPER is the ONLY person who knows how the details about the system behaviour.

Without TDD, your KEY DEVELOPER is the ONLY person who knows how the details about the system behaviour.

Only they can maintain the system.

When other developers make changes, they make mistakes. It then has to be reviewed by the key developer because they “know it better”.

When the key developer goes on vacation, you’re in trouble!

With TDD, your WHOLE TEAM has access to knowledge about the system’s behavior.

The whole team can maintain it.

You no longer have knowledge silos.

You no longer have a knowledge gatekeeper.

Vacations are not a problem. New team members are not a problem.

TDD + Clean Architecture democratizes knowledge about your product.

It removes your “key developer” risk. You’re no longer dependent on the one super-star developer. You don’t have to worry when they’ll be on vacation.

HOW do we achieve all this?

Firstly, with Clean Architecture, USE CASES are first-class citizens.

Use cases are no longer some document produced by the business analyst, but they are directly embedded in the architecture itself.

Now, where do we document our use cases?

“Let’s write use cases on paper”

Hmm… perhaps in the good old days…

“Let’s write use cases in Confluence”

Well, at least the use cases are then stored electronically, and everyone can access them, but what happens when they become out-of-date? When there isn’t time to update them? Or no one wants to update them? Or they are updated incorrectly? How useful and reliable are they?

Can we record the use cases in such a way that they are ALWAYS up-to-date, that they are always accurate, always reliable… the only “source of truth”?

The only source of truth about the actual behavior of a software system is ONLY in the code itself.

So we need to write use cases in code language.

This means, writing TESTS for the USE CASES!

The tests serve as executable documentation of the behavior of the use cases.

When the behavior changes, then the tests are updated, and the code is updated.

When a developer accidentally performs a change in code and which causes a regression bug (i.e. the system doesn’t behave how it was meant to) – no worries, tests will fail and will tell the developer that they broke the system’s behavior.

When a new developer joins the team, they will have access to the up-to-date “executable” documentation of the whole system! When the new developer needs to implement a new feature, a change, or a bug fix, you can rest assured that they won’t break the expected system behavior. If they do, they’ll immediately get feedback and can resolve it.

TDD + Clean Architecture enables us to have always-up-date executable documentation about our use cases.