Figuring Out the Test You Missed is Job One

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”

TDD and Code Coverage

It’s not unusual these days for development organizations to adopt a code coverage requirement. This is usually expressed as a percentage: at least X% of all code developed must be covered by tests.

Measurement tools are used as a process gate, where the team must achieve this minimum coverage level before code can be checked in. This is pointless and may be dangerously misleading. Code coverage tools can only measure how many lines of code are executed by tests, but not what the test do with the results of that execution. Continue reading “TDD and Code Coverage”

TDD Tells Us What is not Known

You cannot meaningfully test that which you do not adequately understand. The time to find that out is before you start development. TDD tells us what we do not know. Sometimes, it tells us what our stakeholders don’t realize they also don’t know.

Imagine you are developing the software for a casino’s poker slot machine (loosely based on a real case). Part of the behavior needed is to shuffle the “cards”, mixing them up into a new order. That would be the stated requirement. If we try to write a test about this, we realize that this is not nearly detailed enough. What is meant by a “new order”? How new? How will we know when the shuffling is adequate? Are there any regulatory requirements about this? Industry standards? Not being casino experts, the developers probably don’t know and would ask the customer. The customer might realize that they aren’t clear themselves.

Testing something requires far more rigor than most people apply to their businesses, and that means the development team that does TDD not only finds good questions to ask, but can also help the customer to more fully understand their own business domain. At times, this leads them to realize even more business value than they knew they wanted.

How Much Testing is Enough?

A typical question those adopting TDD ask is: How much testing is enough? Or, put another way, does everything really need to be tested? How do you decide what to test and what not to test?

It’s an interesting question, but I prefer to address it this way: everything will be tested. The real question is, by whom? Will it be you, or someone else? Continue reading “How Much Testing is Enough?”

TDD and Coupling

In TDD, the test suite can serve as a tool for quantitatively analyzing the qualities present (or absent) in the production code.

One example: A test will need to access the production entity that it is testing, obviously. However, sometimes a test needs to access another entity or entities as well, even though they are not currently under test. We sometimes refer to these collectively as a “fixture” for the test.
Continue reading “TDD and Coupling”

The Multiple Values of Doing TDD

Tests pay you back for your effort:

  • When you are writing them.  They help you to understand the problem you are attempting to solve, they reveal gaps in your knowledge, and lead you to useful questions.
  • When they fail.  They inform you of a defect, and if written well, specifically where that defect is.
  • When they pass.  When you are enhancing or refactoring the system, tests passing confirms that you are only making the changes you intend to make.
  • When you read them later.  Tests capture knowledge that might otherwise be lost.  And their accuracy can be instantly confirmed at any time in the future, by running them.

TDD does not cause extra work.  It is just the opposite; it is one effort that provides value in multiple ways.

Tests are Reactive: They Pass or They Fail

A test reacts to everything currently in scope that it does not control.  Ideally, that should be only one thing. Everything else in scope must be controlled by the test, or it may react to the wrong thing and give misleading results.

For example, if a production entity uses a service call as part of its implementation, and the service being called is not what the test is testing, then that call must be controlled by the test because it is in scope.

This is a major reason to use a mock object.

A Green Test Alone Proves Nothing

Automated tests pass by default. A red test turning green proves everything.

The red test proves the validity of the test (that it can fail).  Tests that cannot fail indicates an error in the way they are written.

The green test proves the code is accurate to the test. The code is written to pass the test, and so we know that it will forever be covered by the test going forward.

The transition from red to green proves that the test and the code are connected to each other. This is because we make failing test pass not by changing the test, but by changing the code.

TDD creates, therefore, meaningful test coverage. Nothing else can ensure this.

Test-Driven Development is not Merely “Test-First”

Test-first yields analysis, it helps us determine what is clear, what is unclear or missing, and ferrets out misunderstandings. Unit tests are unforgiving, they don’t let you get away with anything.

But Test-Driven Development also creates better design. Bad design is hard to test, and so moving tests into a primary position reveals the pain of a bad design very early, before much commitment has been made to it.

Write your tests first, but learn how to listen to what they tell you about your product design.

Test-Driven Development (TDD): The First Leg of Emergent Design

I am heartened by the surge in TDD training. To me, TDD is the second most important thing for devs to learn. ATDD is the first.

TDD is not just the automation of unit testing. It’s also intended to improve design and sustainability.

TDD’s formulation of tests, prior to code, drives design. High quality code is easy to test. The reverse is also true. Code that is easy to test is higher quality than code that isn’t. I labeled this quality, “testability,” in my book Design Patterns Explained. Test-First is a process where deciding on your tests before writing your code improves your design. Continue reading “Test-Driven Development (TDD): The First Leg of Emergent Design”