Behavioural-driven development (BDD) is a software development process and an extension to test-driven development (TDD) .
Some of the challenges a business might face when trying to develop or Extend a software application could include making sure the development team understand what needs to be built. On the other hand, the business will need to define clearly the end result expected.
BDD helps bridge the communications gap between the development team and relevant Stakeholders.
To assist the BDD process, there are several tools available depending on the programming language being used. In Java and Ruby there is Cucumber, and in C# we have Specflow.
- Why BDD with Specflow
- Feature Files
- Sample Feature File
Pre-requisite and Tools:
Why BDD With Specflow?
Specflow works with feature files, which starts with the description of the functionality being tested, and a list of relevant scenarios and their steps.
Requirements contained in the feature files are discussed before they are actually worked on, possibly during grooming sessions. Everyone is on the same page right from the beginning. This means the development team are more likely to deliver the correct requirement.
These feature files will usually reside within the Test Automation Solution. They will equally be version controlled just like the source code, hence, they can serve as a form of living documentation which can be executed, and will be always up to date. If application changes, test execution will fail and will need to be updated.
With good and easily understandable documentation, a wider audience can be reached and new members joining the team will be able to get on board quicker.
Specflow provides out of the box, Data driving capability, Test Script Reuse in the form of Step Bindings and Example tables.
Another beauty of Specflow is the ability to help control the flow of execution through the use of Hooks, Tags, Prioritization. More on this Later.
To assist the BDD process, a form of DSL (domain-specific language) written in simple language e.g. English, French etc. can be used. Software behavior can be described without the implementation details.
Simple statements containing the business requirement can be written in Gherkin Syntax. Scenarios are generated from the requirements and are converted into executable tests to be used to validate the functionality of a System or Application.
This is the file that will house the Features, Scenarios and Steps written with the Gherkin syntax.
The extension is usually '.feature' when using Specflow.
Below shows the simple structure of a feature file.
The Name of the feature file will be the Noun describing the functionality of the system. The file will usually start with the 'Feature:' keyword followed by the Name. The Header will be a description of the Functionality/ Feature that will be tested. A common way this is written is in the format;
In order To …..(Accomplish something)
As An …….. (End user of the System)
I want to be able to … (Perform an operation)
The Scenario will start with the Keyword 'Scenario:' OR 'Scenario Outline:' followed by short description of the scenario.
Steps will start with other Gherkin keywords such Given, When, Then, And, But etc.
Specflow will not treat any of the keywords in any special way. However, it is good practice to use them as follows;
Given - For Setting up the state of the system for testing, usually a known state
When - To Perform an action on the system
Then - Assertion step for the Expected Outcome.
Here is a sample of a feature file in Specflow for a login feature.
I have given two ways of writing the same scenario and test case. How abstract and detailed you want your scenario steps, will depend on your preference and/or the requirement. There is no right or wrong way, however, you must find a balance. If you go into too much detail, for example , you specify element locators from the AUT html webpage in your steps, this defeats the advantage of the business readability gained.
The beauty of Specflow is you get to select your choice of words. For example. I prefer to say 'Input' when typing into a text box , I could have said 'Type in'. A good practice is to be consistent. This will help you find steps for reuse, quicker.
In the next post I will be setting up a specflow project in visual studio. Make sure you subscribe to get notified as soon as it gets published.