Android devices have a massive share of the global user population. Because more and more people are using Android smartphones, app developers need to be able to test their application’s functionality on Android devices just as they would on Windows desktop or Apple...
This article describes how to use the Ranorex Studio IDE and the Ranorex API for test automation in your behavior-driven development (BDD) process. BDD requires a cognitive shift: instead of thinking about testing functions, you are now thinking about behaviors. Following this approach enables seamless collaboration between business stakeholders (such as product management) and the QA or development teams. On the business side, the product management team can define feature specifications in natural language without writing a single line of code. On the technology side, the QA team and the development team add automation steps using code modules and the repository.
Tool Stack
The diagram below shows a sample tool stack to create a BDD-based testing framework. Ranorex Studio provides the development environment and the automation API. To parse the feature files from natural language to written code, we are using SpecFlow as the BDD interpreter. Finally, NUnit is the provider that manages and executes the tests.
Process Overview
When following the BDD approach in an agile environment, the entire development process of a user story is divided into a business side and a technology side.
On the business side, we create user stories, which are taken and broken down into features stored in feature files. These features are broken down into scenarios. The features are written down in a natural language following the Gherkin syntax. A basic feature written in Gherkin might look something like this:
Feature: Serve coffee In order to earn money Customers should be able to buy coffee at all times Scenario: Buy last coffee Given there are 1 coffees left in the machine And I have deposited 1 dollar When I press the coffee button Then I should be served a coffee
On the technology side, we first need an interpreter to parse the feature files and call test automation code. Then, Ranorex API can do the following:
- Automate the actions in system under test
- Verify the expected output
- Return a corresponding result
Prepare Ranorex Studio for BDD
The SpecFlow Add-in for Ranorex Studio
The SpecFlow add-in provides file templates for feature files, step definition files and event definition files. It also translates the features from Gherkin syntax to C# code. To install the SpecFlow add-in to Ranorex Studio, follow the instructions below:
- Download or clone the SpecFlow repo.
- Copy folder named Ranorex SpecFlow AddIn and paste in the <Ranorex Installation folder>Bin\Addins\Misc.
- Copy folder named NUnit.ConsoleRunner.3.
15.2 and paste it to the location from which you want to run tests. You have to copy it to debug folder of the solution where .rxtst resides.
Make your Ranorex Solution BDD ready
In your Ranorex solution open the “Package management console” (View->Tools->Package management console) and run the following command:
Install-Package SpecFlow.NUnit -Version 3.9.74 – Source “https://www.nuget.org/api/v2/
You will notice that the references are added to the projects view.
Change output type to “Class library”. To do so, open the project properties and set the output type of the project to “class library”.
Also, copy all Ranorex runtime DLLs to the output folder. To achieve that, in your solution explorer under references, find the Ranorex references and ensure that Local copy is set to True. Do this for all the Ranorex references.
To ensure that your BDD solution integrates seamlessly with SpecFlow and NUnit you will need to amend the AssemblyInfo.cs and app.config. Simply double click on each in the projects view.
For the AssemblyInfo.cs add:
[assembly: NUnit.Framework.Apartment(System.Threading.ApartmentState.STA)]
as seen below:
C#
For the app.config you will need to add the following section:
Refer to the example below:
C#
Get started with BDD
Now that your Ranorex Solution is BDD-ready, you can begin defining features in SpecFlow and creating automated tests for them in Ranorex. Or, you can import feature files created by DesignWise or any other technology that supports Gherkin syntax and generates feature files.
Step 1 – Define a feature from the business side
Option A: Create within Studio
In SpecFlow, create a new feature file. To do so, right-click on the project, then choose Add > New Item > Category: SpecFlow > SpecFlow Feature.
.
Option B: Import features files created by DesignWise (or another technology that generates feature files)
Once you have the SpecFlow add-in installed you can import .feature files into Ranorex and have them converted to C#.
In a Ranorex solution, right click on the workspace name, click Add-> Existing Item, select the feature file.
Check the created feature file.
For either option, Ranorex Studio will create a
If the code/C# file is not created please refer to the troubleshooting section at the end of this blog.
Step 2 – Create step definitions for the technology side
Create a new step definition file. To do so, right click on the project and choose Add > New Item > Category: SpecFlow > SpecFlow Step Definition.
Now, create methods for all “Given,” “When,” and “Then” actions described in the scenario description. Add “Given”, “When” and “Then” attributes with values matching the scenario steps defined in the feature file. To do so, follow the samples provided by the template from which the new step definition file has been generated.
If you are transitioning from traditional scripting to BDD, Studio has a couple more features that assist you. First, you can use the code of existing, recorded steps by viewing & copying it from the Actions table. And second, your methods can be set up in a fashion that would also take advantage of the repository and its ability to propagate object updates – by utilizing a line like this:
public static {Your project repository name} repo = {Your project repository name}.Instance;
Your implementation might look something like this:
C#
You can create additional steps to be executed before and after a scenario, such as performing setup and tear down tasks, including starting and closing the system under test.
These steps can be defined in either step or event definition file and might look something like this:
C#
Once all the modifications are done, save the file and build the solution again.
Step 3 – Execute a BDD test using NUnit
To summarize, by this step you need to have 3 elements inside the Studio project: the feature file, its interpretation (.feature.cs file, auto-generated when building the solution), and the step definitions file.
Because this flow uses NUnit as the test provider, we use a NUnit Runner to execute our tests.
Your command line call should look something like this: (Use root folder)
{path to the Console Runner}\NUnit.ConsoleRunner.3.15.2\nunit3-console.exe “{path to the test solution Debug folder}\<solution>.dll”
By default, the runner creates a report in NUnit3 XML format which is supported as-is by some of the tools. But you can also choose to install an add-in which converts it to JUnit with this line adjustment:
–result=junit-results.xml;transform=nunit3-junit.xslt
The results folder (the directory you run the command from) will also contain a report in the standard Ranorex format.
Conclusion
The preparation of Ranorex for BDD is complete. From this point forward, your business team can define user stories in a natural language following the Gherkin syntax, and your development and QA team can implement the automation steps in the step definition files.
All-in-one Test Automation
Cross-Technology | Cross-Device | Cross-Platform
Troubleshooting
Assembly not found
If your assembly was not found you will need to build your project as a library. To do so, open the project properties and set the output type of the project to “Class library”. In addition, copy all Ranorex runtime DLLs to the output folder by setting Local copy to True.
Related Posts:
7 Best Android Testing Tools
There are more and more Android testing tools available for mobile app developers. These are our favorites for performance, accessibility, and security.
What Is the Difference Between Regression Testing and Retesting?
Regression testing and retesting are essential methodologies testers employ to ensure software quality. If you’re new to both or aren’t sure when to use which technique, this article should help. We’ll discuss the importance of regression testing in software testing. ...
DevOps Test Automation Tools & Best Practices
DevOps test automation enables teams to work faster and create better products. These best practices and tools make it easier to implement test automation.