How to fail at TDD?

How to fail at TDD?

TDD is painful for many teams.

But over time, we learned to accept the pain.

No pain, no gain. Does it have to be that way?

But what if there was another BETTER way?

What if the way we’re doing TDD now isn’t the way it was originally envisioned?

MISCONCEPTION #1 – The class is the unit of isolation

Write a test class for each production class.

Write a test method for each production method.

Isolate the class under test by mocking out all its collaborators.

MISCONCEPTION #2 – Unit Tests must be expensive

It’s normal for test code to be 2-4X larger than source code.

It’s normal that writing unit tests takes up so much time.

It’s normal that unit tests break when we refactor class design.

Anything that’s worthwhile must be painful. No pain, no gain, right?

MISCONCEPTION #3: BDD is about behaviour, TDD isn’t

ATDD and BDD are about behaviours. They are about testing our system from the user’s perspective.

TDD is not about system behaviour, it’s about testing classes and their interactions with other classes.

When we’re under pressure and when the budget is tight, let’s just keep ATDD/BDD. It actually tells us if we satisfied user requirements.