Month: February 2019

I mentioned earlier that TDD offers qualitative measurements about production code, namely that a large average fixture size can be used to measure relative coupling in a system. Similarly, tests can reveal whether, and to the extent, that the Single Responsibility Principle has been adhered to.

The Single Responsibility Principle states that every class in a design should have a single responsibility. It is an aspect of cohesion in design. The reason that tests will reveal when this principle has been violated has to do with the number of tests needed for that class’ behavior. Continue reading “TDD and the Single Responsibility Principle”

In TDD, there are always more potential scenarios to test, other than the “happy path” of desirable behavior. We need a way to decide how far to go.

This is often a question of risk assessment. Having a framework for thinking about risk can be useful. Consider this framework that has two dimensions: Likelihood and severity. Crossing these produces a four-quadrant matrix. Continue reading “A Framework for Thinking About Risk”

In many large organizations there is a kind of wall between development and testing. Developers do their work and “throw it over the wall” to be tested. This can create negative attitudes on both sides.

Developers see testers either as a source of no information (“it works? Yeah we knew that”) or bad news (“there are bugs to find and fix, ugh”). Testers are adversaries to overcome before developers can be said to have succeeded.

Testers see developers as a source of hard work, and code that must be wrestled with. Often testing lags hopelessly behind development and because of this testers see developers as a source of a never-ending avalanche of work.
Continue reading “TDD Makes Developers and Testers into Valued Colleagues”

Project Managers and Product Owners are sometimes dubious about the development team doing TDD. They are concerned that the team will slow down because they’ve been burdened with additional work, and that developers might “game” the system with bogus tests to satisfy the process. Also, it seems like a nonsensical idea to write a test for something before that thing exists.

All of these concerns are addressed by the observation that, despite its name, TDD is not really a testing activity. The “tests” that are written in TDD are actually the specification of the system.

The effects of this shift in thinking are profound. Continue reading “TDD Provides Value to Everyone in the Development Process”

Defects can either be prevented or detected.

Let’s say you write a method in C# that takes, as its parameter, one of the nine players on a baseball team.

If you decide to make that parameter an integer (1 is the pitcher, 2 is the catcher, and so forth), then the code will still compile if a number greater than 9, or less than 1, is passed into the method. You will have to take some action in the code if that happens: correct the data, throw an exception, something along those lines. This code would be written to “detect” the defect, and would be driven from a failing test in TDD.

On the other hand, we would not have to allow for the possibility that someone will pass a non-integer, like 1.5, into the method, because the compiler will not allow this. Anything the compiler, linker, IDE, etc. will not allow is considered a “prevented” defect. Continue reading “Figuring Out the Test You Missed is Job One”