BDD’s fundamental function is to afford stakeholders the chance to understand all facets of a project by using straightforward language instead of hard-to-read code. That is to say, this BDD testing approach allows to build tests that depict the system’s anticipated behaviour as well as the users’ needs.
Below you can see a basic BBD test scenario and a piece of code that has been implemented with the traditional functional approach. The difference in readability is visible at first sight, isn’t it?
A basic BDD test scenario.
Code that has been implemented with the traditional functional approach.
From this example, it’s obvious that a BDD test is easier to understand and allows all members from the team to get to grips with whatever requirement or function is being tested. When it comes to Agile, we are able to clearly show what each automation script covers, in terms of acceptance criteria, user story or feature. Consequently, producing BDD test scenarios demands considerable more effort.
Let’s look at a comparison of the traditional approach with BDD when using Cucumber, a tool that generates executable specifications.
Typically, behaviour-driven development is utilised for UI end-to-end testing; however it is also appropriate for unit testing, such as Jasmine or Cucumber, performance testing and API testing.
In addition to the easy-to-understand scripts, BDD offers a sizeable boost in project clarity, as well as the opportunity to cut down time spent on long-term endeavours. One of my biggest pet peeves is when only the engineer who executed a project’s tests can understand their results. BDD turns pages of hard-to-read code into text that is understandable by everyone, from managers and assistants to analysts and customers.
Of course, test implementation is not a project’s core activity; support and test execution generally takes longer than the initial test writing; however, if you take a look at the time and energy spent on investigating issues and analysing test results, it’s easy to see the benefit in being able to troubleshoot failed BDD scenarios quickly.
Being able to easily spot which step of a particular feature has fallen short and why, as well as being able to recognise a link between a business requirement and a failed test, puts you in a unique position when it comes to providing stakeholder feedback in a timely and understandable fashion.
Even though BDD testing offers a lot in terms of potential benefits, there are some drawbacks to take into consideration before opting to use the BDD approach for your next project:
BDD is not a panacea, but like any other technology, it can make a difference when it comes to the success of appropriate projects. If the list of statements below applies to you, BDD implementation should be your next step:
If you would like some assistance with your BDD project or if you have a question relating to what BDD can offer you, get in touch with us.
First version published on UTest