Behavior Driven Development SpecFlow - Behavior Driven Development

What is SpecFlow?

SpecFlow is an open-source project used by SpecFlow to save an acceptance criterion for various features (use cases, user stories) in the application as prescribed by the Gherkin syntax. . Usually the source code is hosted on GitHub.

The Gherkin format was invented by Cucumber and used by other BDD tools also. The Gherkin language is considered as a project on GitHub − https://github.com/cucumber/gherkin

Feature Elements and SpecFlow

The main 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

If the scenario includes more than two steps then it is called as multiple scenario steps. Then three types of steps that describes 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 called as markers which can be allocated to features and scenarios. Assigning a tag to a single feature is equivalent to assigning the tag to all scenarios included in the feature file. A Tag Name with a leading @ denotes tag.

  • It supports unit test framework, where SpecFlow creates categories from the tags.
  • The generated category name will be 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 is used to mention the common precondition for all scenarios included in a feature file

  • The background part of the file may include one or more scenario steps which are executed before any other steps of the scenarios.
  • SpecFlow creates a method from the background elements that is raised from all unit tests generated for the scenarios.

Scenario Outlines

Scenario outlines are designed to explain about data-driven acceptance tests. The scenario outline includes various scenarios of a scenario template specification (a scenario with data placeholders using the <placeholder> syntax) along with a set of examples which provides values for the placeholders

  • When the unit test framework supports it, SpecFlow creates 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

To add comments to the feature files at any place start with #. Make sure that the comments in your specification will be a sign that acceptance criteria have been mentioned wrongly. SpecFlow ignores comment lines.

Behavior Driven Development Related Tutorials

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Behavior Driven Development Topics