What is the difference between TDD and the testing process?

This is a question I sometimes receive, and I want to share my thoughts on it.

TDD

TDD is a software development methodology that drives development through tests, facilitating the writing of code and building of features or products. Without doing here a full review of TDD, for this article we take the main idea that is about first writing tests and then writing the code that makes the tests pass.

Testing process

From a developer’s perspective, the testing process is a series of activities done to intentionally write tests with the purpose of verifying code correctness, documenting expected behavior, identifying defects or bugs, and improving maintainability.

What is the difference?

First, while doing TDD you should write tests by using test design techniques which are part of the testing process.

Rather than viewing testing and development as two separate phases, consider that TDD involves writing tests so it will include applying testing activities while doing TDD.

Still, we talk about doing testing and doing TDD.

I think the main difference comes from what is called a development mindset and a testing mindset. This difference exists in both TDD methodology and in many others because it is about people and points of view while working.

Development mindset or developer mindset

While being in a development mindset, the focus is more on trying to write code that implements the requirements in any form or shape they were provided. Thus the tests written while in the development mindset are more focused on verifying requirements or proving that the code works as expected and requirements are met.

From practice while being in development mindset there are more positive scenarios written than negative scenarios. Keep in mind that it is considered positive scenario also when you are verifying for example than an API will return 404 when record not found. While this might be a failure from point of view of the user trying to access that page, is a positive scenario because it tries to assess an expected behavior of the product.

The same goes for thinking about tests as documenting behavior. They will mostly be focused on the positive scenarios.

There is also a bias there called developer bias. That means that once a solution is created (either written, explained or thought about) the developer is more likely to write tests that are passing, thus it is more inclined to demonstrate (with tests) that the code is working as expected or that the solution is the right one instead of trying to find the solution that solves the requirements.

Testing mindset or tester mindset

In the testing mindset, the focus is more on making sure the code is reliable, consistent predictable, and it will not return unexpected results.

Thus, tests written while being in the testing mindset are focused more on edge cases of undocumented behavior; it is more concerned with the questions "What happens if ...?" and "What happens when ...?".

The tests written are mostly negative scenarios, and so they are inspired by the idea of what could possibly trigger a bug.

TDD and Testing Process

In the first phase of building a feature and applying TDD, we mostly live in the development mindset.

That is both natural and good for making progress and being efficient as a developer.

We want to first make the code work as expected with a focus more on the functional characteristics of the code and less on the non-functional attributes (performance, security, ...). Less does not mean not paying attention to non-functional attributes while coding but it is more about what kind of tests are written during this first phase.

Then, after the functional part of the requirements is implemented, we want to make sure the code is, for example: reliable, consistent, predictable, maintainable, and performant. You can choose other non-functional/code quality attributes.

During this second phase you can still use TDD (and if you are familiar with it, please do so) but the tests driving the development should be generated while being in the testing mindset. Refactor the code to make these tests pass, thus improving the quality of the code.

One trick for the testing mindset

One trick to switch to a testing mindset is to re-read the requirements, open a test file, think about what cases you want to test, and just write the names of the tests.

The tests will be higher quality if you write all of the cases first and then fill in the test code (preconditions, initial state, assertions) instead of writing the first test, run it, then write the second test, run it, and so on.

Whether we like it or not, writing test code is still development, and you will get back in the developer mindset before you get to think about what to test next.