Listen to this post
Specifying a workflow in #TDD means writing a test that says, “When entity A is called upon to accomplish a task, it must interact with entity B is the following way.” This is done when the interaction in question is part of a required workflow, and not simply an implementation decision that should be changeable.
The best way to accomplish this is to create a mock of entity B. Such a mock would “log” how it is used by entity A at test time, and then allow the test to examine the log and compare it to what should have happened. There are many ways to accomplish this.
However, care must be taken to engage in this form of testing only when the workflow is part of the customer-defined specification. Doing it in other cases will create excessive coupling between the tests and the system under test. This hamstrings any refactoring efforts that follow.
This is one problem with automated mocking tools. They make this kind of “logging” activity extremely easy to do, and thus the team may do it too much without realizing this. These tools can be quite powerful and can help to increase the velocity of TDD, but they should be used with care in this respect.