Test-Driven Development in the Larger Context: Pt 2. Cadence

Another key difference between ATDD and UTDD is the pace and granularity, or “cadence” of the work.  This difference is driven by the purpose of the activity, and how the effort can drive the maximum value with the minimum delay.

CADENCE

 

ATDD

Acceptance tests should be written at the start of the development cycle: during sprint planning in Scrum, as an example.  Enough tests are written to cover the entire upcoming development effort, plus a few more in case the team moves more quickly than estimates expect.  

If using a pull system, like Kanban, then the acceptance tests should be generated into a backlog that the team can pull from.  The creation of these tests, again, are part of the collaborative planning process and should follow its pace exactly.

Acceptance test start off failing, as a group, and then are run at regular intervals (perhaps as part of a nightly build) to allow the business to track the progress of the teams as they gradually convert them to passing tests.  This provides data that allows management to forecast completion (the “burn down curve”) which aids in planning.

The primary purpose of creating acceptance tests is the collaboration this engenders.  The tests are a side-effect (albeit an enormously beneficial one) of the process, which is engaged to ensure that all stakeholders are addressed, all critical information is included, and that there is complete alignment between business prioritization and the upcoming development effort.

When training stakeholders to write such tests, the experience should be realistic; work should be done by teams that include everyone mentioned in the “Audience” blog that preceded this one, and they should ideally work on real requirements from the business.

 

UTDD

A single unit test is written and proved to fail by running it immediately.  Failure validates the test in that a test that cannot fail, or fails for the wrong reason, has no value.  The developer does not proceed without such a test, and without a clear understanding of why it is failing.

Then the production work is done to make this one test pass, immediately.  The developer does not move on to write another test until it and all previously-written tests are “green.” The guiding principle is that we never have more than one failing test at a time, and therefore the test is a process gate determining when the next user story (or similar artifact) can begin to be worked on.

When training developers to write these tests properly, we use previously-derived examples to ensure that they understand how to avoid the common pitfalls that can plague this process: tests can become accidentally coupled to each other, tests can become redundant and fail in groups, one test added to the system can cause other, older tests to fail.  All of this is avoidable but requires that developers who write them are given the proper set of experiences, in the right order, so that they are armed with the necessary understanding to ensure that the test suite, as it grows large, does not become unsustainable.

Intro
Part 1
Part 2
Part 3
Part 4