Get Started With Cucumber BDD

Misunderstanding vector created by storyset — source

Have you ever in a project with unclear business requirements or differences in understanding that makes uncertain criteria that lead to product failure ? 😢, then you are in the right place, BDD (Behavior Driven Development) is a way for software teams to “closes the gap between business people and technical people”, any further ado let’s discuss what is BDD.

Difference between traditional development process & BDD

In a traditional development process the user tells the product owner what he wants, the business analyst then writes a requirements document and give it to developer (where the developer have a responsibility to translate the requirements into software) and tester (where the tester will translate the requirement into test case). Here we see that each role is only responsible in their own way.

BDD development process

Whereas in BDD, after the user tells what he wants, the three amigos (product owner, developer and tester) will elaborate the requirement together and the output of this discovery is a set of scenario behaviors in a set of documentation that developers, testers and all stakeholders can understand and access.

With BDD user stories can clearly illustrate the relationship between app features and business goals. Encouraging collaboration across roles to build shared understanding of the problem to be solved and producing system documentation that is automatically checked against the system’s behavior.

Cucumber

We talked about BDD earlier and there is a documentation that understand by developers, testers and all stakeholders, the question is how to achieve that?, then lets talk about cucumber.

Cucumber is a tool that supports BDD, Cucumber reads executable specifications written in plain text, the specifications consists of multiple examples, or scenarios, each scenario is a list of steps for Cucumber to work through, in order for Cucumber to understand the scenarios, they must follow some basic syntax rules, called Gherkin, for more documentation refer here.

Example feature scenario

Above is an example of login scenario, gherkin documents are stored in .feature text files, so i create a file with Login.feature name, if you want to make feature file you can install visual studio code and add this extention for auto complete, if you want to use other editor you can find here

Ok let’s check the example above

• Feature keyword is to provide a high-level description of a software feature, and to group related scenarios, next line is a description of the feature.
• Rule keyword is to represent one business rule that should be implemented this is (optional)
• Scenario Outline keyword can be used to run the same Scenario multiple times.
• Given describe an initial context (precondition)
• When describe an event or action by user or triggered by another system.
• <email> dynamic value, where will change by the example value when run.
• And If you have successive Given’s, When’s, or Then’s.
• Then describe an expected outcome or result (report, user interface, message)
• Examples of your state or value for your feature.

So that’s how to build the feature file and you can share that file as a guide for your team and other stakeholder 😃. If you like this article you can give me a 👏 and if you have a question we can discuss in the response section, thank you.

Bonus 🎁

If you curious how the feature file guide the android developer, you can find my article here, and if you want to know how to make a test case from a feature file with katalon studio, you can find here 👍