Claysnow

Every journey is just a collection of steps

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.

stairs_0011-physical

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.

Posted

in

by

Seb Rose

Tags:

Comments

3 responses to “Every journey is just a collection of steps”

  1. Hugo Baraúna Avatar
    Hugo Baraúna

    In a ideal world, I would like to have a cucumber feature for each (XP) user story. But, by doing that, I would end up a with a lot of Cucumber features and really small scenarios. The end result would be a slow cucumber teste suite. That’s the problem.I heard people are trying to fix that problem building less granular cucumber scenarios, in what they’re calling a user journey, not a user story. A user journey would be a cucumber scenario testing a set of user actions that make sense from a business point of view.What do you think about that? Did you had any problems writing small cucumber scenarios for each user story? Do you have any suggestions or solutions?

    Reply
  2. Hugo Baraúna Avatar
    Hugo Baraúna

    Nice post! I was wondering if you’re familiar with the concept of using user journeys as a base for test scenarios and how you would compare using user journeys X using user stories for your acceptance test scenarios.

    Reply
  3. Seb Rose Avatar
    Seb Rose

    Hugo, I think a few user journeys are very useful for demonstrating that the deployed application is ‘wired up’ correctly. They can also be useful to give the business a feel for some of the interactions. Using too many of them leads to a brittle specification that will be slow to execute and difficult to understand.I like to keep in mind the Testing Pyramid (see my earlier post on the Testing Iceberg) and keep the end-to-end tests to a minimum. Then I can create plenty of thin, granular acceptance tests that exercise as little of the application as makes sense, while still presenting behaviour that is of interest to the business. As long as these scenarios don’t use the whole application stack there’s no reason why they should be any slower than unit/integration tests.The main insight is that the ‘thickness’ of an automated example (i.e. how much of the application stack it exercises) is orthogonal to its readability (i.e. whether it should be surfaced in the acceptance tests or the technical/unit tests).

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *