- Behavior Driven Development
- BDD - Home
- BDD - Introduction
- BDD - Test Driven Development
- BDD - TDD in a BDD Way
- BDD - Specifications by Example
- BDD - Tools
- BDD - Cucumber
- BDD - Gherkin
- BDD - SpecFlow
- BDD Useful Resources
- BDD - Quick Guide
- BDD - Useful Resources
- BDD - Discussion
Behavior Driven Development - SpecFlow
SpecFlow is an open-source project. The source code is hosted on GitHub. The feature files used by SpecFlow to store an acceptance criterion for features (use cases, user stories) in your application are defined using the Gherkin syntax.
The Gherkin format was introduced by Cucumber and is also used by other tools. The Gherkin language is maintained as a project on GitHub − https://github.com/cucumber/gherkin
Feature Elements and SpecFlow
The key features of Feature elements are −
The feature element provides a header for the feature file. The feature element includes the name and a high-level description of the corresponding feature in your application.
SpecFlow generates a unit test class for the feature element, with the class name derived from the name of the feature.
SpecFlow generates executable unit tests from the scenarios that represent acceptance criteria.
A feature file may contain multiple scenarios used to describe the feature's acceptance tests.
Scenarios have a name and can consist of multiple scenario steps.
SpecFlow generates a unit test method for each scenario, with the method name derived from the name of the scenario.
Multiple Scenario Steps
The scenarios can have multiple scenario steps. There are three types of steps that define the preconditions, actions or verification steps, which make up the acceptance test.
The different types of steps begin with either the Given, When or Then keywords respectively and subsequent steps of the same type can be linked using the And and But keywords.
The Gherkin syntax allows any combination of these three types of steps, but a scenario usually has distinct blocks of Given, When and Then statements.
Scenario steps are defined using text and can have additional table called DataTable or multi-line text called DocString arguments.
The scenario steps are a primary way to execute any custom code to automate the application.
SpecFlow generates a call inside the unit test method for each scenario step. The call is performed by the SpecFlow runtime that will execute the step definition matching to the scenario step.
The matching is done at runtime, so the generated tests can be compiled and executed even if the binding is not yet implemented.
You can include tables and multi-line arguments in scenario steps. These are used by the step definitions and are either passed as additional table or string arguments.
Tags
Tags are markers that can be assigned to features and scenarios. Assigning a tag to a feature is equivalent to assigning the tag to all scenarios in the feature file. A Tag Name with a leading @ denotes tag.
If supported by the unit test framework, SpecFlow generates categories from the tags.
The generated category name is the same as the tag's name, but without the leading @.
You can filter and group the tests to be executed using these unit test categories. For example, you can tag crucial tests with @important, and then execute these tests more frequently.
Background Elements
The background language element allows specifying a common precondition for all scenarios in a feature file
The background part of the file can contain one or more scenario steps that are executed before any other steps of the scenarios.
SpecFlow generates a method from the background elements that is invoked from all unit tests generated for the scenarios.
Scenario Outlines
Scenario outlines can be used to define data-driven acceptance tests. The scenario outline always consists of a scenario template specification (a scenario with data placeholders using the <placeholder> syntax) and a set of examples that provide values for the placeholders
If the unit test framework supports it, SpecFlow generates row-based tests from scenario outlines.
Otherwise, it generates a parameterized unit-test logic method for a scenario outline and an individual unit test method for each example set.
For better traceability, the generated unit-test method names are derived from the scenario outline title and the first value of the examples (first column of the examples table).
It is therefore good practice to choose a unique and descriptive parameter as the first column in the example set.
As the Gherkin syntax does require all example columns to have matching placeholders in the scenario outline, you can even introduce an arbitrary column in the example sets used to name the tests with more readability.
SpecFlow performs the placeholder substitution as a separate phase before matching the step bindings.
The implementation and the parameters in the step bindings are thus independent of whether they are executed through a direct scenario or a scenario outline.
This allows you to later specify further examples in the acceptance tests without changing the step bindings.
Comments
You can add comment lines to the feature files at any place by starting the line with #. Be careful however, as comments in your specification can be a sign that acceptance criteria have been specified wrongly. SpecFlow ignores comment lines.