In this tutorial, we will create some tests in Cucumber/Gherkin, using SpecFlow and C# and we'll import the results to Xray to have visibility of the test results.
There are some possible workflows related with Cucumber.
In this tutorial, we assume that the the tests (specification) are initially created in Jira as a Cucumber Tests and exported afterwards using the UI or the REST API; that's what we call the "standard" workflow.
If you prefer to manage the .feature and respective Scenarios outside of Jira, like in your own local dev environment/IDE or in Git/SVN, then you'll need to synchronize the specification to Jira as depicted in our VCS based workflow.
- Install SpecFlow and the SpecFlow+ Runner 1.7.2 or newer along with the msbuild helper package; If you're using Visual Studio, just go to NuGet's Console (Tools | NuGet Package Manager | Package Manager Console)
- Install-Package SpecRun.SpecFlow
- Use the
CucumberJson.cshtmlreport template provided in this page
In this tutorial, we detail more extensively the standard Cucumber workflow (more info in Testing in BDD with Gherkin based frameworks (e.g. Cucumber)), where Xray/Jira is used as the master of information, i.e. the place where you edit/manage your Cucumber Scenarios.
An alternate approach would be using your IDE, or the feature files persisted in Git for example, as the master of information. In that case, the workflow is a bit different as we'll mention ahead.
Using Xray and Jira to manage the Scenario specification
In this use case, Cucumber Tests are written in Jira using Xray of type "Scenario" or "Scenario Outline", in Jira.
You can export the specification of the tests to a Cucumber .feature file via the REST API or the Export to Cucumber UI action from within the Test Execution issue.
The created file will be similar to the following one.
The actual step implementation code lives outside of Jira. Thus, you have to make the implementation for each step/sentence.
Before compiling and running the tests, you have to use a proper SpecFlow report template file in order to generate a valid Cucumber JSON report and you have to configure the test profile to use it.
Tests can be run from within the IDE (e.g. Visual Studio) or by the command line; in the later case, make sure to specify the profile name and all the paths properly.
Since there is code-behind file generation, it is required to have the NuGet "SpecFlow.Tools.MsBuild.Generation" package.
After running the tests and generating the Cucumber JSON report (e.g., data.json), it can be imported to Xray via the REST API or the Import Execution Results action within the Test Execution.
Since the original feature was extracted from a Test Execution, the results will be updated on it (this happens because the .feature file contains the Test Execution's issue key as a tag).
If the .feature was created by hand directly on your IDE, or managed elsewhere outside of Jira, and it didn't contain the Test Execution's key, then a brand new Test Execution would be created. This would also happen in case it was extracted using the REST API based on Test/requirement issue keys.
The execution screen details will not only provide information on the overall test run result, but also of each of the examples provided in the Scenario Outline and on the respective steps.
Managing the Scenario specification in your IDE, in Git or in other VCS
In this case you are using your IDE as means to write/edit the Scenarios and eventually persist them in the VCS (e.g. Git, SVN, other) so they can be run during Continuous Integration.
In this case, you'll need to regularly synchronize the specification to Jira as depicted in our VCS based workflow.
We also recommend that the .feature contains some auxiliary tags using the syntax
id:xxx in each Scenario/Scenario Outline, to better guarantee that Scenarios are always mapped against the same Tests in Xray.
Before running the Scenarios, in order to produce a Cucumber JSON report that can be properly processed by Xray, we need to use the features extracted from JIRA instead of the ones we edit, because they will contain:
- tags corresponding to Test issue keys
- tag corresponding to the related Test Execution key, in case we want to use an existing Test Execution as the criteria to select the Tests to be run
- tags corresponding to the related requirement(s)
Please see Testing in BDD with Gherkin based frameworks (e.g. Cucumber) for an overview on how to use Cucumber based Tests with Xray, and the VCS based workflow for the later example.
- Testing in BDD with Gherkin based frameworks (e.g. Cucumber)
- Exporting Cucumber Tests - REST