How do I decide what a feature should be? And should I define a feature first before writing behavior specs, or should I start with behaviors and see how they fit together into features?
Features, scenarios, and behaviors are all common BDD terms that should be carefully defined:
- A behavior is an operation with inputs, actions, and expected outcomes.
- A scenario is the specification of a behavior using formal steps and examples.
- A feature is a desired product functionality often involving multiple behaviors.
Don’t try to over-think the definition of “feature.” Some features are small, while other features are large. The main distinction between a feature and a scenario or behavior is that features are what customers expect to receive. Small features may cover only a few or even only one behavior, while large features may cover several.
The Gherkin language has Feature and Scenario sections. In this sense, a Feature is simply a collection of related Scenarios. They align roughly to the more general meanings of the terms.
Don’t over-think features with Agile, either. Some teams define a feature as a collection of user stories. Other teams say that one user story is a feature. In terms of Gherkin, don’t presume that one user story must have exactly one feature file with one Feature section. A user story could have zero-to-many feature files to cover its behaviors. Do whatever is appropriate.
Features should be determined by customer needs. They should solve problems the customers have. For example, perhaps the customer needs a better way to process orders through their online store. That’s where features should start – as business needs. Behaviors should then naturally come as part of grooming and refinement efforts. Thus, in most cases, features should be identified first before individual behaviors.
Nevertheless, there may be times during development that scenario-to-feature realignment should be done. It may be more convenient to create a new feature file for related behaviors. Or, a new feature may be “discovered” out of particularly useful behaviors. This is more the exception than the norm.
I have a scenario where a user create some entity and retrieves it later to see the data thats saved in backend as part of create. Now, can creating the entity in backend and retrieving the data be combined as a feature? or should there be two features – one for creating the entity and other for retrieving the entity? If it can be done in both ways – what are advantages of one over other?
LikeLike
Creating and retrieving are two actions tied together. You need to retrieve in order to verify that creation was successful. I’d say combine them. Action != Behavior.
LikeLike