People seem to love workflow style scenarios. What is it about a workflow that is so irresistible?

I was talking about this with Kevlin Henney the other day, and he pointed out that it might be because business processes are the staple diet of modern organisations. A workflow is a natural expression of one journey through a business process, and so is a simple way to create an acceptance test that aligns with something of business value.

The problem is that this style of scenario is inherently brittle and difficult to parse. There’s so much going on, so many moving parts, that it’s hard to reason about as a whole.

Instead, I encourage people to consider a workflow as a journey made up of many smaller steps. By exploring the behaviour of each step in its own scenario we make the scenarios more robust to changes and easier to reason about. And if one of the steps has a number of variants, as they so often do, we can focus on this variation in a set of scenarios dedicated to that particular part of the workflow, instead of muddying the water with bags of extraneous detail.


Even if you think that you have to go through a whole bunch of setup steps to get to the point in the process that you’re interested in, then wrap that up in a single step definition that encapsulates those steps. Initially you might implement this step definition by driving your applicatio through the GUI. Later you’ll find that there will be simpler ways to do this be interacting directly with the domain layer, or by setting up stubbed data sources.

You’ll still want one or two end-to-end scenarios to demonstrate that the process hangs together as a whole, but these are there to demonstrate that the application components are wired up correctly, rather than to explore specific business functionality.

Make light of your journey by exploring it one scenario at a time.