Listen to this post
The term “workflow” in this sense is meant to indicate the way two system elements interact when performing a task. Often these interactions themselves are not exposed outside the system, and so only their resulting behavior should be tested. This is as true in TDD as it is in traditional testing.
Most workflows are implementation details that developers should be able to change so long as the right behavior is still achieved. If the developers have a better idea, or technology improves, these changes should not break tests.
However, there are some workflows that are part of the specification and should not be altered. For these we must have a test.
Consider a system that has a layer which provides access to a database. In this case it is critical that all accesses to the database go through this layer (where, perhaps, business rules or regulatory requirements are enforced). We realize that it would be possible for a developer to “go around” this layer and directly access the database (perhaps for performance) without realizing that this violates a requirement.
TDD should have this critical workflow specified in a test which would now fail, alerting the developer to the error immediately.
How to do this will come next.