Tuesday, 3 December, 2019 UTC
Summary
What development styles do you utilize in your company – perhaps TDD, ATDD, or BDD? There’s a sheer endless variety of acronyms that involve different mobile development and testing practices. To shed some light on what’s what, we’ve discussed the most popular methods on our blog before. Today, we’re going to dive into BDD (Behavior-Driven Development), see how it works in mobile testing processes and how it can help you streamline workflows and create high-quality mobile applications.
What Is Behavior-Driven Development?
In a nutshell, BDD aims to close the gap between technical and business teams by fostering effective communication and collaboration toward a common goal.
Before developers write a single line of code for a feature, the three amigos (e.g., developers, testers, and the product owner) come together and review each of the feature’s User Stories and write down examples that describe the expected outcome. The goal is to develop a shared understanding of the desired system’s behavior.
A developer or tester pair then takes these examples and formulates them into scenarios, using a shared language (domain-specific language, DSL for short). Thanks to the DSL, anyone in the team can understand these scenarios and system behaviors. Finally, a developer writes “glue” code to turn the defined scenarios into executable specifications that also serve as living documentation.
As a result, your teams continuously collaborate using small but fast iterations, making sure your mobile application behaves as your customers expect.
What Are the Pros (And Cons) of BDD for Mobile Testing?
Of course, BDD’s business value depends on how you integrate it into your workflows and how well your team adapts and adjusts it.
Organizations that utilize BDD report that it can be time-consuming – especially in the beginning. But again, if you blend the method effectively into your business, you will save time in other places.
Think about it: If everyone gets on the same page before developers write code, you won’t need to discuss and correct specific behaviors after the development phase. Consequently, you save time by getting things right the first time.
Let’s hear more benefits that come with BDD:
- It encourages collaboration and improves communication between non-technical teams, developers, and testers.
- Everyone is involved in the process right from the start. As a result, the risk of unwanted outcomes by uninformed employees is minimized.
- Your teams’ spirits get lifted because everyone has a common goal to work toward.
- Everyone knows how the system should behave thanks to the non-programmatic language with which it is described.
- Business experts and product owners can communicate their expectations more effectively, making sure the final result meets all expectations.
Basically, you can divide BDD into three main steps:
- Discovery
- Formulation
- Automation
Let’s see how the things we’ve learned so far fit into these parts.
Discovery
In this phase, the three amigos come together, pick a User Story for an upcoming feature, and discuss the required behavior from the user’s point of view. These meetings are often referred to as discovery workshops and are essential to building a common understanding between participants. Additionally, these meetings can help teams identify features that aren’t required for a User Story and thus allows you to continuously iterate in smaller steps.
The outcome of these discussions – the concrete examples – become the automated tests in the next step.
Formulation
Now it’s time to formulate the scenarios with the examples from the previous step.
For this, ideally, a pair of developers or testers must document these scenarios in a domain-specific, shared language (DSL) collaboratively. As described before, this language helps to establish a shared understanding as anyone can read and write in that language. In this way, hopefully, all misunderstandings can be eliminated before the first line of code is written.
Automation
As mentioned above, developers then write “glue” code that links the business readable text to the developed system. These executable specifications can then be run by an automation framework for BDD, like Cucumber, which we will talk about in more detail shortly.
In BDD, your developers follow a test-driven development (TDD) style, about which you can read more here. Basically, test-driven development means developers focus on writing code that passes these tests – nothing more. As a result, developers always know what to do and don’t waste time on features that aren’t required at the moment.
In the future, whenever your engineers must change the code, they can use the living documentation to understand what the system is currently doing, i.e., what it’s supposed to do. Thus, they can adapt code more straightforwardly while ensuring your app’s functionality and behavior.
Hands-On Example of Mobile Testing with BDD, Cucumber, and Gherkin
Let’s get to the more hands-on part of this article and see how you write examples in BDD.
First, we need something that can run the test scripts. Cucumber is by far the most popular BDD automation framework in the community, helping to ensure the system behaves as intended. Teams from different industries use this framework – naturally, you can also leverage BDD with Cucumber for your mobile app development and testing!
Tip: Cucumber only supports Java, JavaScript, Ruby, and Kotlin. Hence, you can’t use it to test your native iOS apps out of the box. However, you can find other tools that build on Cucumber that help you meet your mobile testing needs. For example, use the Objective-C Cucumber Wire Protocol for iOS that your developers and testers can easily integrate with XCode.
Each scenario is a list of steps that Cucumber runs through to verify whether your app does what it should.
The DSL, in which you write scenarios for Cucumber, uses the Gherkin syntax – the community’s favorite DSL for BDD automation. Like any other language, Gherkin defines a specific set of grammar rules you need to follow for Cucumber to understand them. Basically, with Gherkin, you can write scenarios that your team and Cucumber can understand!
Let’s look at a concrete example:
Feature: Sign up for Newsletter Users want to sign up for our newsletter Scenario: Signing up with a valid e-mail address Given I am on the Newsletter Signup page When I fill the e-mail text field with value '[email protected]' And I click the Signup button Then I should be told 'Thanks for signing up!'
Each scenario written in Gherkin follows the Given, When, Then syntax.
These keywords help you define what should happen when in your mobile app. Naturally, it may take some time for your team to get accustomed to this syntax. But once they’ve mastered it, they can write scenarios with ease!
Now, your developers would take the scenario above and implement the desired feature following the test-driven development approach.
Enhance Your Development and Testing Process with BDD and CucumberTip: If you’re interested in the whole process, check out this 10-minute tutorial on Cucumber, which perfectly illustrates the workflow.
BDD can definitely help you improve the quality of your mobile app by making sure it behaves as customers expect, resulting in a better user experience. However, you don’t need to throw your currently used methods completely overboard when introducing mobile development and testing processes with BDD! Naturally, it can complement most other methods such as TDD.
Whether you create apps using Java, Objective-C, or JavaScript – Cucumber is an excellent automation framework that you can expand with additional third-party tools to fit your needs. Above all, BDD should improve your development cycles and not create new hurdles for your team. That’s why you need to experiment and see for yourself how it works out.
Image by Pexels via [source link] (copyright-free)
The post Enhance Mobile Dev & Testing Process with BDD and Cucumber appeared first on Bitbar.