You are doing TDD Wrong

Verify this short checklist to be sure that you are extracting the maximum potential of TDD.

Photo by Brett Jordan on Unsplash

When TDD was born, most companies were practicing Waterfall. TDD was born outside the Waterfall context, and it applied some concepts differently. Unfortunately, when new practitioners adopted TDD, they carried with them their own context, and some niceties were lost. That misconceptions carried mistakes that nowadays affect almost any TDD development.

Here I present three typical mistakes that programmers should stop doing.

Question 1: Are you using mocks?

It is quite common to think that TDD produces Unit Tests. That is correct, but. There are two definitions for Unit Test: the QA definition says that a Unit Test failure implicates only one unit, the Agile definition says that a Unit Test failure implicates only one behavior. TDD uses the Agile definition.

You should use the Agile definition. That means that your test should avoid mocks, and test as integrated as possible. QA definitions about unit, integrated, or e2e tests are not relevant here. The programmer must use the kind of test that gives more confidence.

If you are a programmer, you may ask how do I quickly found the source of a failure if…