Gáspár Nagy, SpecFlow/BDD coach, trainer, and test automation expert talked about how to write better BDD scenarios and what practices can be applied to achieve this goal.
Many have heard of Behavior-driven development, even if they haven’t used it yet. And the first thing that comes to mind when mentioning this software development methodology is BDD scripts, the central element of BDD itself.
Table of Contents
Benefits of BDD Scripts
Gáspár Nagy sees the BDD script as a bridge connecting the requirements for software development and the app being created.
But why build a bridge between these elements? From a business perspective, to make requirements testable. It is essential to comprehend that it’s the requirements that are being tested, not the code. And on the delivery side, to make the tests clearer, especially when it comes to a complex system or integration tests.
If the purpose of these scripts was only automated testing, you could find an alternative to it. But they solve several problems:
- illustration of requirements;
- documentation of behavior, especially in agile projects.
Essence of BDD
Behavior Driven Development is about understanding, documenting & verifying business requirements via illustrative scenarios. BDD is primarily focused on functional and business requirements.
When you put this into practice with a team that uses the BDD method, you should be prepared to do three things:
- Discovery – shared understanding is established through cooperation and structured conversations.
- Formulation – system behavior examples are documented as scenarios.
- Automation – Scenarios are automated to verify the behavior of the system.
Formulation is an activity when we document domain examples as BDD scenarios with Given/When/Then.
Typical activities done during formulation:
- Identify context, action, and outcome (Given/When/Then).
- Is this preparation step crucial to be able to get the expected outcome?
- Review/fix business terminology to be used.
- Are we calling them “Client” or “User”?
- Turn the scenario into proper English sentences (grammar tenses, word
ordering, etc.)
- As this has happened earlier, we should use the past tense for this step.
- Reuse existing phrasing styles from other scenarios or even complete steps.
- I think we had a scenario that described a similar problem. Let’s look at that.
- Make sure the steps make a sequential flow (so it is possible to automate
them).
- Another user should have created the question to be voted earlier; otherwise, we cannot vote for them!
Anatomy of a Scenario
BDD script consists of:
- Name (title) – identifies the scenario (“The one where…”)
- Given – describes the context.
- And – continuation of the previous step.
- When – the action that initiates the behavior.
- Then – the expected outcome.
The Gherkin Syntax
Scripts are generated in a format called Gherkin syntax. It is characterized by:
- Business-readable specification language.
- Using the concept of the Given/When/Then keywords.
- Developed as part of Cucumber but promoted to a tool-agnostic format.
- Open-source parser for 10+ development platforms / programming languages.
- Designed to be simple, therefore it lacks programming constructs.
- No conditions.
- No variables.
- No loops.
Principles of Good Scenarios
- Business language: business terminology aids cross-discipline collaboration.
- Real data: using actual data helps reveal assumptions and edge cases.
- Intention revealing: describe the desired outcomes rather than the mechanism of how they are achieved.
- Essential: omit any information that doesn’t directly illustrate behavior.
- Focused: each scenario should only illustrate a single rule.
- Brief: shorter scenarios are easier to read, understand and maintain.
Summarizing
Formulation is used to document examples and make them ready for automation. The scenarios should be connected to business rules. Scenarios should follow BRIEF principles: business language, real data, intention revealing, essential, focused, and brief.
