What is Behaviour Driven Development?
eXtreme Programming (XP) and Test-Driven Development (TDD) have been around for a long time. The idea was for stakeholders and testers to write automated tests that expressed their desired outcome from the system. These would fail to begin with as there was no code to test against, but as the software was developed and the tests begin to pass, then there is a level of acceptance that the software behaves as required (automated acceptance tests).
However, XP and TDD are quite often seen as developer tasks, and there are challenges in writing automated tests before the software is available.
Agile incorporated the ideas of XP and TDD, with the concept of small iterations of development, where ‘User Stories’ are collaboratively written by stakeholders, testers and developers to describe what the software is expected to do in simple English. Automated Tests and development of the system then takes place against these User Stories.
BDD is simply an extension of this, where we specify a behaviour and we develop it and we test it:
- We start with a definition of what we want (User Story)
- We elaborate to define features that we think will provide that story
- We define test scenarios to ‘prove’ the feature
But all of this is still done in an easy to understand English language.
BDD fits well into the Agile Methodology as feature files elaborate on the user stories and their outcomes. BDD differs from TDD, as we do not document the low-level test steps in BDD, but describe examples of actions/events that the user undertakes and the outcomes from those events.
For example, a Test Case may be:
Test Name: Search for Edgewords in Google
Step 1, Open Firefox and go to URL ‘www.google.com’, expected: Google home page is loaded
Step 2, click in the search field and type ‘Edgewords’ and click Enter, expected: search results are returned
Step 3, validate that ‘Edgewords’ appears as one of the returned search values
Whereas in BDD we would simply put:
Scenario: Google Search for ‘Edgewords’
When I search for “Edgewords” on the Google search page
Then “Edgewords” appears in the results returned
BDD provides an easy to use concept, with a way of describing the system under test that everyone can understand. It is also available not just in English but in many localised languages.
As with Agile, many organisations tailor methodologies to meet their own requirements, but here is a typical example of the BDD process in the real-world under Agile:
- The business has a need or goal. They discuss it and firm up on what they want (and when)
- The product owner will produce some draft Stories for entry in the backlog – they do not need to have an exact form or defined acceptance criteria at this point!
- The process of refinement then takes place – this is driven by the priority of the backlog entry from a business perspective
- The Objective is to end up with an Epic and or lower level Stories that can be implemented in a reasonable timeframe
- At the point where there is a basic consensus on the content of a Story – the process of working out the effort and acceptance criteria begins (note all this can be before a scrum – or actually be the point of a scrum).
- Here the 3 amigos will meet and agree the Features and Scenarios for test
This structure and mapping of the BDD at this point (use tagging and directory structure) provide a mechanism to later get a view on coverage
The object is to end up with 1..n Feature files to cover a Story; 1..n Scenarios to cover a Feature.
Then the execution status (Excluded, Pending; Failing; Passing) defines the acceptance coverage.
Tools for BDD
The most common framework tools for BDD are Cucumber and SpecFlow.
Cucumber started in 2007/8 using Ruby as the programming language so its been around a long time now. Cucumber-JVM (Java), started in 2012. Cucumber is now available for a whole host of programming languages.
SpecFlow is the .NET version of Cucumber, and is commonly used with C# in Microsoft Visual Studio IDE.
When we write our Feature File, we have to use a specific syntax, and this language is called Gherkin.
So Feature Files (just text files) are written in Gherkin, then Cucumber or SpecFlow are used to parse the Feature Files and call associated automation code. Which automation tool you use, again, is up to you! You could use Selenium WebDriver, HPE LeanFT, Ranorex, there are plenty of choices out there.
This is only a sample of the tools available, there are open source as well as commercial tools available for implementing BDD. Also, many different flavours depending on your chosen programming language preference and the technology of the system you are testing.
Take a look at this Webinar Video for a practical example of using BDD. In this case using SpecFlow with Selenium WebDriver:
BDD courses from Edgewords:
- BDD using Cucumber and Selenium WebDriver Java – 2 days, Classroom, London & Birmingham
- BDD using SpecFlow and Selenium WebDriver C# – 2 days, Classroom, London & Birmingham
- BDD using Cucumber-js and Selenium WebDriver JavaScript – 2 days, Classroom, London & Birmingham
For the schedule and prices, please see our course schedule at: www.edgewordstraining.co.uk/automated-software-testing-training-courses/bdd-cucumber-specflow-training/
Why use Edgewords?
Edgewords has been delivering training in automated testing for over a decade and is recognised as one of Europe’s leading providers in this field. All of our trainers have at least 10 years testing experience, so can provide expert advice on industry best practices.
All of our courses are practical, written by testing consultants, so you really learn how to develop real-world tests and overcome common problems you will experience along the way.
Comprehensive workbooks are provided that act as a great resource after the course when you need to start developing automated tests on your own.
Simply call us on +44 (0)333 939 8884 or submit an enquiry form here and we will assist you in finding the most suitable course for your needs.