Page History
...
| Note | ||||||
|---|---|---|---|---|---|---|
| ||||||
Code is available in GiHubon GitHub; the repo contains some additional tests beyond the scope of this tutorial and some auxiliary scripts. |
...
Behave (and Cucumber) can be used in diverse scenarios. Next, you may find some usage patterns, even though using Behave usage is mostly recommended only if you are adopting BDD.
- Teams adopting BDD, start by defining a user story and clarify it using Scenario(s); usualyusually, Scenario(s)/Scenario Outline(s) are specified directly in Jira, using Xray
- Teams adopting BDD but that favour favor a more Git-based approach (e.g. GitOps). In this case, stories would be defined in Jira but Behave .feature files would be specified using some IDE and would be stored in Git, for example
- Teams not adopting BDD but still using Behave, more as an automation framework. Sometimes focused on regression testing; sometimes, for on non-regression testing. In this case, cucumber Cucumber would be used...
- With a user story or some sort of "requirement" described in Jira
- Without any story/"requirement" described in Jira
...
Before moving into the actual implementation, we you need to decide which workflow weyou'll use: do we you want to use Xray/Jira as the master for writing the declarative specification (i.e. the Gherkin based Scenarios), or do we you want to manage those outside using some editor and store them in Git, for example?
...
| Info | ||
|---|---|---|
| ||
Please see Testing in BDD with Gherkin-based frameworks (e.g. Cucumber) for an overview of the possible workflows. The place that you'll use to edit the Gherkin Scenarios will affect your workflow. There are teams that prefer to edit Scenarios in Jira using Xray, while there are others that prefer to edit them by writing the .feature files by hand using some IDE. |
...
The test (specification) is initialy initially created in Jira as Cucumber Tests and afterwardsafterward, it is exported using the UI or the REST API.
This tutorial , has the following requirements:
...
To generate .feature file(s) based on Scenarios defined in Jira (i.e. Cucumber Tests and Preconditions), we can do it directly from Jira, by the REST API, or using a CI tool; we'll see that ahead in more detail.
Step-by-step
All Everthing starts with a user story or some sort of “requirement” that you wish to validate. This is materialized as a Jira issue and identified by the corresponding issue key (e.g. CALC-1206).
...
The coverage and the test results can be tracked in on the "requirement" side (e.g. user story). In this case, you may see that coverage changed from being UNCOVERED to NOTRUN (i.e. covered and with at least one test not run).
...
We repeat the process for additional "requirmentsrequirements" and/or test Scenarios.
The related statement's code is managed outside of Jira and stored in Git, for example.
...
You can then export the specification of the test to a Cucumber .feature file via the REST API, or the Xray - Export to Cucumber UI action from within the Test/Test Execution issue or even based on an existing saved filter. As a source, you can identify Test, Test Set, Test Execution, Test Plan, or "requirement" issues. A plugin for your CI tool of choice can be used to ease this task.
...
In order to run the tests there 2 options available:
- Use Using the native Behave JSON (JSON pretty) report => recommended way
- Or use Using a custom reporter that generates a compatible Cucumber JSON report
...