Assertion Driven Design (ADD)

In all cases of using a unit test framework, no matter the intent of the test methods, one thing is certainly true: Assertions are being fired.

When we Assert with a unit testing framework before the software we are writing passes the assertion, this shapes the form and functionality of the software we are building.

This is obviously using external assertions as a design tool. We are asserting the software will have a behavior, a state, or some other quality. Then we make it so.

This is truly Assertion Driven  Design. The ADD part should resonate for many of us, hmm?

We are using one piece of software (the external assertion framework) to shape the think we are actually creating. The product system is incrementally defined by its ability to work cleanly with the external assertion set.

This isn?t testing, it is a constant shaping and exercising of the code we are writing as we write it.

TDD isn?t Testing?

No. It is a unfortunately named practice that should have been called ADD. Writing unit tests as prescribed in TDD is a design activity, not a testing one. Tests are things applied to the SUT after it exists. ADD happens before the software exists.

This is About Design, Duh

By now, we should able to discuss the advantages of TDD without having to claim it is a testing tool.

Check. We got it. Can we move on?

And, it turns out to be true! Writing tests as you go will make better software because it gets implemented more deliberately instead of being shored up reactively later.

Uncle Bob asserted this early on when he originally thought TDD stood for Test Driven Design. Hear that interview here.

I Agree with Scott

I listened to Hanselman?s show with Scott Bellware while taking a walk recently. Bellware makes some excellent points about the way TDD is perceived and the true intent behind BDD (Behavior Driven Development). It also makes sense to me that the word ?behavior? doesn?t quite work, no offense to Dan North.

BDD is an excellent idea and one that has matured the idea of using these frameworks to create better software. In practice, Behavior is fairly ambiguous term. It carries some baggage of implication with it.

Is ADD simply rebranding? Sort of. But we can also recognize that sometimes we want an assertion on on system that might not look like GIVEN_WHEN_THEN. BDD is an excellent form of ADD, but may not allow for the whole story in every system we craft.

Unit Testing Tools Also Make Good Testing Tools

There is also tremendous value in sometimes writing an integration test using a unit test framework. Sometimes it is a file operation. Sometimes it is an actual data load.There are lots of scenarios where it makes sense.

While these tests are not unit tests, they are easily implemented with a unit test framework. They also add value, often as regressions. The only advice I would offer here is to separate these tests from the unit tests, both in development and execution.

Recognize that these are genuinely tests and are typically not to be considered design aids.Writing a system test with a unit testing framework is not ADD. It is testing. And is often a valuable thing to do.