Scenarios are grouped into Stories which are very similiar to the Agile concept of User Stories.
A story is composed of one or more scenarios. The story describes the common requirements of its scenarios in the style of a User Story.
To actually express the behavior we want, each story contains several scenarios. Each scenario is a single concrete example of how the system should behave in a particular situation. If you add together the behavior defined by all of the scenarios, that’s the expected behavior of the story itself.
When JBehave runs a scenario, if the system behaves as described in the scenario, then the scenario will pass; if not, it will fail. Each time you add a new scenario to your JBehave test suite and make it pass, you’ve added some new functionality to the system, and that’s time for a high-five.
Each story typically has somewhere between five and twenty scenarios, each describing different examples of how that feature should behave in different circumstances. We use scenarios to explore edge cases and different paths through a feature. We use scenarios to explore edge cases and different paths through a story.
Each scenario is a list of steps for JBehave to work through.
Scenarios all follow the same pattern:
- Get the system into a particular state.
- Poke it (or tickle it, or ...).
- Examine the new state.
So, we start with a context, go on to describe an action, and then finally check that the outcome was what we expected. Each scenario tells a little story describing something that the system should be able to do.
A scenario consists of steps which need to be performed in the scenario.
Steps are of different types:
- Given - a precondition is realized or checked by the user
- When - this is an action which is performed by the user
- Then - verifies a postcondition of the system under test