When we talk about behaviour driven development (BDD), inevitably we will discuss feature files at some point. Whilst the focus of BDD should always be on conversations and shared understanding, feature files are a valuable output of the collaborative process - so long as we create and use them wisely.
Misinterpreting feature files can cause problems for a team; if they’re used incorrectly, this can bias our work in negative ways, create extra work, and at worst affect our product's quality. In this post we are going to deep dive into the role of a feature file, and explore how they interact with other team activities.
How feature Files and user stories differ
One common misconception is that user stories and feature files are two sides of the same coin, but this is not the case. Way back in 2010, Matt Wynne wrote about how feature files are not the same as user stories and even gave some examples of why this anti-pattern can lead to problems, such as saturation of feature files and a duplication of effort as you formalize processes around tying user stories and feature files together.
That’s not to say feature files and user stories don’t have any relationship, but to understand how they work together we need to understand their purpose. As Matt says:
"User Stories are a planning tool. They exist until they’re implemented, and then they disappear, absorbed into the code."
User stories
User stories help us plan and track what we want to build.
We use them to track that we’ve discussed the requirements and behaviour of the feature, as well as the development and testing of the feature.
Once those activities are done, the user story can then be discarded or placed elsewhere.
Feature Files
Feature files are a library of our product.
As we document the behaviour of our product before developing them, it builds a detailed map of the important behaviour of our product.
They evolve as our product evolves.
Thus, instead of the relationship between user stories and feature files being direct and exclusive, user stories simply contribute to the changing of feature files rather than creating a new feature file for every single user story.
Separating user stories from the feature File
Let’s look at an example, where a team has created a feature that allows gold loyalty members to upgrade their hotel booking. An example of the behaviour of a gold loyalty member upgrading a booking has been documented in a feature file as a scenario:
Feature File: Booking upgrade
Scenario: Gold member upgrades booking
Given a guest has a standard room reservation And the guest is a gold loyalty member When there are superior rooms available for the length of their stay Then the guest has the option to upgrade to a superior room
Now imagine that the team starts work on a new user story which allows standard users to upgrade their booking, but because they’re not gold members they need to pay an upgrade charge. Our initial reaction might be to create a new feature file but beware; since the new work is an extension to the current booking upgrade feature we can add examples to the existing upgrade feature file to show the new behaviour that is being added. We may even update existing examples if there are changes to the upgrade behaviour for gold members too:
Feature File: Booking upgrade
Scenario: Gold member upgrades booking
Given a guest has a standard room reservation And the guest is a gold loyalty member When there are superior rooms available for the length of their stay Then the guest has the option to upgrade to a superior room for free
Scenario: Standard member upgrades booking
Given a guest has a standard room reservation And the guest is a standard loyalty member When there are superior rooms available for the length of their stay Then the guest has the option to upgrade to a superior room for £50
Once the feature has been developed, the user story is removed from the plan but the feature file is up-to-date reflecting the new behaviour.
Well-organized feature Files are a valuable resource
A healthy library of feature files provides us with an informative view of the key behaviours of our products. They can be used to explain how features work for businesses and end users, so it is important that feature files are organized in clear and concise way which makes them easy to access and read.
We need a clear appreciation of how feature files should be used to ensure we can extract full value from them.
Focus on using them as a tool to document behaviour, by collecting valuable information from user stories through discussion and collaboration.
Organize them in a clear way that focuses on features and behaviours, rather than on user stories.
If we want to gauge the current state of our feature files, we should ask other team members and stakeholders if they are reading our feature files. Are they feeding back on them? If they’re not, then perhaps something needs to change!
This article was originally posted on our blog, you can check it out as well as many others here.