Test Driven Development can be a business process, not just a development
workflow. It can start much earlier in the software engineering process than
when implementation starts and code is first written.
Quite a few engineering teams confuse TDD for doing any testing at all, but even
teams that know TDD is a stronger process than that still limit its potential by
confining it to an implementation workflow detail that is trivial at the level
of the business or software team.
TDD can actually be a business-level methodology for successfully producing and
maintaining software. As the name suggests, the “test” comes first and
foremost when working on software in any way. But this does not just refer to
test code that is executable on a machine. It means a verifiable description of
a behaviour or process, which is actually what software is all about.
Start with a test case. That doesn’t mean do selection, planning, sizing and
design first, then hand it over to a developer who might remember to try and
write some test code first. It means start with a strong behaviourial
description as the starting point.
Some organisations half-ass this with acceptance criteria that occasionally
appear on a minority of tickets when the organisation is paying attention, but
even then might be added at any stage of development. The boat has usually
sailed by that point as vagueness and ingenuity seep into the project.
This behavioural description does not need to be actual test code in a
programming language; that is not the point. The point is that the idea of the
desired behaviour is kept controllable from the beginning. Successful software
is about control, not just of machines but of meaningful processes and business
behaviour. If we can’t control this, the difficulty is dramatically increased
and failure becomes more likely.
Simpler systems are easier to control and they fail less
often. Focusing on controlling
behaviour and process from the start (whether or not you call that TDD) keeps
things simpler and increases the chance of success.
Focusing on verifiable descriptions of behaviour as the primary driver of
software development can control this – we are forced to produce controllable
systems if we are going to consistently prove that they work in a meaningful
With this mindset, the shiny new technologies are suddenly less appealing, as we
sacrifice control by handing it over to them, and are left with much weaker
options to demonstrate and maintain the desired functionality of the system.
You are not doing Test Driven Development