Cucumber is a testing framework that supports Behavior Driven Development (BDD). It lets us define application behaviour in plain meaningful English text using a simple grammar defined by a language called Gherkin.
What is SpecFlow?
SpecFlow is inspired by the Cucumber framework in the Ruby on Rails world. Cucumber uses plain English in the Gherkin format to express user stories. Once the user stories and their expectations are written, the Cucumber gem is used to execute those stores.
Why BDD Framework?
Let’s assume there is a requirement from the shaadi.com website to increase the sales of the product by implementing some new features on the website. The only challenge of the development team is to convert the client idea into something that actually delivers benefits to the client.
The original idea is awesome. But the only challenge here is that the person who is developing the idea is not the same person who has this idea.
With the help of the Gherkin language cucumber helps facilitate the discovery and use of a ubiquitous language within the team. Tests written in cucumber directly interact with the development code, but the tests are written in a language that is quite easy to understand by the business stakeholders.
The BDD methodology used is based on the NLP (natural language program) concept. Where the information of semi-automatically produce a step definition and code framework. The scenarios are given in the natural language and then applied to Software Testing.
Recently, in our organization, I have performed a BDD POC Msite testing using Cucumber katalon. I was not able to find a lot of help on it online. Even more so, I was able to find solutions that were hard to understand and were only limited to using java frameworks like spring boot. More details on how that works can be found. I would say that my solution is also inspired by this and I have tried to solve the problem using some of the features provided out of the box by katalon.
Here is the ReG Flow video which is executed using the BDD framework:
Now that we have our project on which we can start testing, let’s talk about the tool we are going to use today. Katalon is fairly new in the market when you compare it with the tools like selenium but it packs a punch nonetheless. It allows non-technical people like manual testers to integrate and develop test automation scripts. It also allows seamless integration with Git, Jira, and DevOps to maintain an ecosystem of quality engineering.
I will delve into the solution by explaining my feature file first. Feature files are the pieces of documentation in BDD which bring the complete team or stakeholders on the same page about a system’s working or functionality.
In the above snippet, we are following the gherkin format as required.
ADVANTAGES OF BDD
BDD is meant to be collaborative. Everyone from the customer to the tester should be able to easily engage in product development. And anyone can write behaviour scenarios because they are written in plain language. Scenarios are:
- Requirements for product owners
- Acceptance criteria for developers
- Test cases for testers
- Scripts for automation
- Description for other stakeholders.
BDD is designed to speed up the development process. Everyone involved in development relies upon the same scenarios. Scenarios are requirements, acceptance criteria, test cases, and test scripts all in one – there is no need to write any other artefact.
BDD frameworks make it easy to turn scenarios into automated tests. The steps are already given by the scenarios – the automation engineer simply needs to write a method/function to perform each step’s operation.
BDD is an evolution of TDD. Writing scenarios from the beginning enforces quality-first and test-first mindsets. BDD automation can run scenarios to fail until the feature is implemented and causes tests to pass.
Given-When-Then steps can be reused between scenarios. The underlying implementation for each step does not change. Automation code becomes very modular.
- Because communications between the user and the developer are essential, if the user is not available, it will be difficult to work past ambiguities and questions generated by the user stories.
- The second disadvantage is the need to dedicate a team of developers to work with the client. The short response time required for the process means high levels of availability.
- Write the scenario after you’ve written the code.
- BA/Product Owner creating scenarios in isolation.
- Testing several rules at the same time.
- Scenario with either a bad name or no name at all.
- Adding pointless scenario descriptions.
- No clear separation between Given, When, and ThenScenarios form a collection of self-documenting test cases as a result of the BDD process. This ever-growing collection forms a perfect regression test suite. Scenarios can be run manually or with automation.