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 apppcation 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 apppcation.

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 pnked 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-pne text called DocString arguments.

The scenario steps are a primary way to execute any custom code to automate the apppcation.

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-pne 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 Outpnes

Scenario outpnes can be used to define data-driven acceptance tests. The scenario outpne 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 outpnes.

Otherwise, it generates a parameterized unit-test logic method for a scenario outpne and an inspanidual unit test method for each example set.

For better traceabipty, the generated unit-test method names are derived from the scenario outpne 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 outpne, you can even introduce an arbitrary column in the example sets used to name the tests with more readabipty.

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 outpne.

This allows you to later specify further examples in the acceptance tests without changing the step bindings.

Comments

You can add comment pnes to the feature files at any place by starting the pne with #. Be careful however, as comments in your specification can be a sign that acceptance criteria have been specified wrongly. SpecFlow ignores comment pnes.