Behavior-Driven Development has made project communications and testing more efficient, especially when using Cucumber, a communication, requirements, and testing tool all rolled into one. Read on to learn more about both, and why 303 Software uses these methods to support high-quality coding and keep technical requirements from getting lost in translation.
Speaking the Same Language: BDD, Cucumber, and the Three Amigos
Behavior-Driven Development (BDD) is a process of exploring, discovering, defining, and achieving the desired behavior of a software system. It applies language simplification and ground-floor, cross-team conversations between technical experts and product owners to ensure expectations are aligned from a project’s inception. As a result, BDD helps bridge gaps between business analysts and developers, manual quality assurance methods and automation testers, and quality assurance and developers.
Cucumber is an open-source tool for BDD. It involves conversations, concrete examples, and automated testing to understand the intended behavior of the software to be developed.
As a QA engineer, I’m going to focus on the QA aspects of Cucumber, and will use the term Behavior-Driven Testing (BDT) instead of BDD. BDD is a next-level hybrid of practices from Test-Driven Development (TDD) and Acceptance Test-Driven Development (ATDD), so BDT can be adapted for testing even if the development team does not follow BDD.
BDT improves efficiency throughout the stages of development by:
- Pulling stakeholders and delivery teams onto the same page
- Aligning stakeholders’ expectations
- Making test reports easier to understand for any reader
- Saving time during coding by using snippets from failed tests
Cucumber’s step-by-step structure, simplified language, and focus on collaborative communication supports these efficiencies.
The Cucumber process begins with one conversation held by three stakeholders: the test engineer, the developer, and the product owner—known in Cucumber as the “three amigos.” This initial conversation is crucial because it exposes misunderstandings and unknowns which could otherwise crop up much further along in development and cause serious delays.
The goal of this discovery conversation is to define concrete examples that describe the software’s desired behavior which can then be tested. After the three amigos meet, their takeaways are translated into Cucumber features and scenarios (which I’ll explain later) using Gherkin language.
Gherkin Language: Cucumber’s Rosetta Stone
Gherkin is a business readable language, which means it’s designed to be easily understood by any reader involved in the development project. It appears as structured, plain-text English (or 60 other languages, an indicator of Cucumber’s growth since its debut).
After the three amigos convene, the development team takes their examples and runs them through Cucumber as automated acceptance tests. Cucumber is used to run the Gherkin features with Selenium WebDriver, failing it and using snippets from the failed tests to drive testing.
Cucumber will then indicate which examples are implemented and working, and warns you about the ones that aren’t. Before you know it, you have one document that contains both the specification and the tests for your software.
Decoding Gherkin: Keywords You Should Know
In Gherkin, each line that isn’t blank has to start with a Gherkin keyword, followed by any text you like. Gherkin uses the following keywords to keep its structure concise and understandable:
- Feature
- Scenario
- The Steps: Given, When, Then, And, But
- Background
- Scenario Outline
- Examples
Here’s a quick breakdown of some essential Cucumber keywords:
- Feature: a stand-alone functionality which contains a list of scenarios
- Scenario: describes an example that we can execute
- Given: the context for the scenario
- When: the action
- Then: the outcome
Together, the terms scenario, given, when, and then explain one single aspect of the behavior of the system. This is how we translate the behavior into Gherkin for BDT.
Let’s take an online shopping app as a common example. Some of its basic features could be:
- Downloading the app
- Registering as a user in the site
- Logging in to the app
- Logging out of the app
These become the features to be used with Cucumber and should be entered in unique feature files, which store features, their descriptions, and scenarios to be tested. Creating a unique file for each feature may seem tedious, but you’ll thank yourself later for staying organized as you go.
Specific features are translated into a Gherkin scenario to be run by Cucumber. If we were to break down user login functionality, the third feature listed above, into Gherkin, it would look like this:
Scenario: The user should be able to login into the app if the username and the password are correct.
- Given: the user has the correct credentials
- When: the user enters the credentials
- Then: the user will be able to log in
In the above example, the scenario is followed by three steps which clearly outline the feature requirements. Note that each step in a scenario needs a matching step definition to translate Gherkin language into system-ready actions.
A step definition is a code with an attached pattern; the pattern connects the step definition to its matching step(s), and the code is executed by Cucumber when it encounters a Gherkin step.
303 Software’s Test Automation Framework: “Simple as Possible, But Not Simpler.”
303 Software follows high-quality code standards to make sure that our code is:
- Reusable by multiple teams and multiple projects
- Familiar to the manual testers
- Scalable and maintainable for developers
- Easy to understand
- Generic and extendable, like UI Testing or Database Testing
As for technical aspects, while Cucumber supports many languages, 303 Software uses Selenium WebDriver in Java (as well as JUnit and Maven). More specifically, our code has wrappable Selenium elements which make the code independent of versions and give the framework our own controls.
Given the rigorous standards 303 Software applies to the code we produce, we rely on BDT and Cucumber to keep our test automation process organized and unambiguous, and it hasn’t let us down.
If you’re in a pickle (you saw that coming) about Business-Driven Development and Testing and want to know more, email us at helloworld@303software.com. We’d love to hear from you!
