On t'internet!
Behaviour Driven Testing is an enhancement of TDD.
In BDD we write tests first and then code.
Tests are written in plain English type grammar.
A testing framework which supports BDD.
It lets us define application behaviour in plain English text
Cucumber uses grammar defined by a language called Gherkin
Gherkin language provide the keyword such as Given, When, Then, And
Specflow is the .NET implementation of Cucumber
Specflow is available in the form of package, which can be installed in project with the help of “NuGet” package manager
Navigate to Tools : Extensions and Updates… and search for Specflow (Online)
Then Select Manage NuGet Packages, search for Specflow and install
App.config
Need to make an additional setting so that Specflow uses MSTest framework for running the test.
Attribute to add
When you click add new item you should see three new entires
Is used to structure the test
We use certain Gherkin keywords to write the test in a feature file.
Cucumber understands the Gherkin language. It parses the file using the grammar provided by Gherkin language.
Hence we say it as Cucumber test.
In Specflow there are two important files
Feature file – will have the test scenario
Step Definition – Which will have the code for the step
Feature Keyword – Each feature file begins with this keyword. This provides the name and description of the feature which is under test.
Scenario Keyword – Each feature will have multiple test. A test is described by scenario keyword.
Given keyword – This keyword defines a preconditions of a scenario
And Keyword – This keyword is used to provide the additional condition to the step. It can be used with Given, When and Then
When Keyword – Use when a given action is to be performed on a web page
Then Keyword – This keyword defines the outcome of the previous step
But Keyword – This Keyword defines negative condition added to the previous step
Background Keyword – This keyword defines the steps which are common across the scenario
Background will run before each scenario in the feature file
You can right click on any of the Steps to generate the step definitions. It will then create a Step Definition file. Each step will be a method in the Step Definition file.
You can have multiple steps the same in feature file but will map to one (the same) method in the Step Definition file.
Most important part of Step Definition file is the [Binding] which will tell during the runtime which feature file is mapped to this definition.
Passing the argument from Feature file
There are 3 ways to pass the argument from feature file to step definition
Parameter – Specifying the parameter directly in step
Data Table – Use to pass multiple arguments
Scenario outline – Use to pass different argument to multiple step
Automatically generated step:
Step:
Have two steps perform the same method:
To run same scenario with different data
Use Scenario Outline keyword and Examples
For the runtime to ignore a scenario
SpecRun actually stops execution after a number of failing tests. This limit can be specified in the .srprofile (EX: Default.srprofile) with the following line.
<Execution retryFor="None" stopAfterFailures="0" testThreadCount="1" testSchedulingMode="Sequential" />
retryFor = "None" will tell SpecRun not to retry a test if it fails an assertion.
stopAfterFailures = "0" will tell SpecRun not to stop after any failures and continue.
Create and Run Subset of Tests Using Playlist in Visual Studio
Select the tests to add, can be feature or individual tests, right click and select Add to Playlist -> New Playlist. You will then be asked to create a file and name it.
You can then select the and run the playlist.
The great thing about SpecFlow is the automatically generated report at the completion of selected tests. Below you can see the summary of tests completed on the Employees Feature file.
Below you can see each scenario that was tested, and the details of the scenario. Failed tests will show as red and skipped tests as amber.
Clicking a scenario shows the scenario details. Below you can see each step in the scenario, and how long it took each step to complete.
The reports are saved as HTML documents. I will typically run each feature file I have seperately on the test environment, before a release to production. I can then just copy and zip the report files to be sent on to management without having to add anything.
Footer