Enhance Your Testing Workflow with Gherkin in Azure DevOps
Arunabh Satpathy- August 28, 2024
Gherkin is a human-readable language central to Behavior-Driven Development (BDD). Teams can create concise, clear, and workable software specifications for all stakeholders. Within platforms like Azure DevOps, Gherkin helps teams ensure that everyone shares a common understanding of project requirements. It communicates and streamlines the testing process, ensuring that specifications are well-defined and directly executable.
In this guide, we explore what Gherkin syntax is, how to write good Gherkin, and how AI can help you generate high quality Gherkin in DevOps. It aims to equip you with insights and tools to fully use Gherkin in DevOps, regardless of your experience level.
1. What Is Gherkin Syntax? What is Gherkin Used For?
Gherkin is a simple and structured language that describes software behavior in plain language. Gherkin syntax is used in BDD to create clear and understandable test cases. Its benefits include:
- Clarity: Gherkin is an accessible test scenario language that is comprehensible to non-technical stakeholders like BAs, testers etc. but structured enough to be useful to programmers.
- Consistency: Gherkin is a standardized format when writing test cases, which ensures uniformity across teams and projects.
- Collaboration: Gherkin enhances communication between devs, QAs, and BAs because of its simplicity.
- Automation: Integrates with frameworks like Cucumber and tools like Selenium, allowing for automated testing of functions.
The basic syntax of Gherkin includes:
- Feature: A high-level description of a software feature.
- Scenario: A specific example or use case that illustrates a feature.
- Given: The initial system state or context.
- When: The action (usually a user action) that triggers a system change.
- Then: The expected outcome.
- And/But: Any extra steps or conditions.
Testers do not have to use every element of this syntax but Scenario, Given, When, and Then are compulsory.
For instance, a Gherkin for a new registrant on an ecommerce website login who uses a too-short password might be:
Given the user is on the registration page
When the user inputs a valid email address but a password that is less than 8 characters long
Then the input should fail
And an error message should display “Password must be at least 8 characters long”
2. What is the Difference Between Gherkin and Cucumber?
DevOps Professionals can sometimes confuse Cucumber and Gherkin. While Cucumber is an open-source tool for executing automated tests, Gherkin is the language used to write those tests by describing specific user and software behavior. Their differences are detailed below:
| Aspect | Gherkin | Cucumber |
|---|---|---|
|
Type |
Language |
Open-source software |
|
Purpose |
Human-readable acceptance tests in simple language |
Executing tests written in Gherkin |
|
Syntax |
Given-When-Then format |
Interprets Gherkin syntax and maps them to code |
|
Integration |
Works with Cucumber |
Integrates with various testing and programming languages and frameworks |
|
Focus |
Clear understanding of expected behavior |
Executes the test |
3. How to Write Good Gherkin Syntax Scenarios?
Well-written Gherkin syntax helps enhance Gherkin’s inherent benefits like clarity, collaboration, automation etc. To maximize these benefits, following certain specific guidelines is helpful:
a. Use Clear and Descriptive Titles
The title of a scenario should succinctly convey the behavior your team is testing. So, write a clear and descriptive title that helps readers quickly understand the purpose of the scenario. For example, a title like “Login process” isn’t as clear and descriptive as “user logs in successfully with valid credentials.”
b. Use the Given-When-Then Format
This format gives context (Given), the action (When), and the expected outcome (Then). For example:
Given the user is on the login page
When the user enters valid credentials and submits them
Then redirect the user to the software functions
c. Avoid Implementation Details
Focus on describing the behavior rather than the implementation. This makes your scenarios evergreen and makes them resilient against UI or code changes.
For example:
If a ‘when’ condition is “When the user enters valid credentials and clicks on the “Submit” button,” then this is a bad example, because the button text may change or 2FA requires more than just credential submission.
d. Scenarios Should Be Concise and Focused
Each scenario should ideally test one specific behavior. Multiple behaviors can lead to confusion and make error detection harder during testing.
e. Avoid Using Conditional Logic
Gherkin aims to maximize clarity. So, it’s best to avoid conditional logic within a single scenario and instead create separate scenarios for different conditions. For example, “When the user clicks on the privacy policy and data sharing checkbox or only clicks on the privacy policy” is an example of a poorly written scenario.
f. Use Asterisks as Bullet Points When Necessary
Gherkin does not support traditional bullet points, but you can use asterisks (*) to create a list format within scenarios. This helps readability.
*Given the user is on the login page
*When the user enters valid credentials and submits them
*Then redirect the user to the software functions
g. Use AI for Gherkin Syntax Generation
Using AI for Gherkin syntax generation streamlines test scenario creation by automating repetitive tasks, ensuring consistency, and reducing human error. AI tools like can suggest improvements to existing Gherkin and generate high quality scenarios based on user stories. Users can also add custom instructions to further tune the AI output for team needs.
h. Review the Scenarios
Regularly review and test your scenarios to ensure they accurately reflect the intended behavior. This helps maintain the relevance and accuracy of your Gherkin. Well written Gherkin will typically require less maintenance over time.
By adhering to these guidelines, you can create Gherkin scenarios that are effective for automated testing and create documentation for stakeholders.
4. Using Gherkin with Azure DevOps
Azure DevOps is one of the most widely adopted DevOps tools in multiple industries like healthcare, banking, manufacturing etc. It integrates behavior-driven development (BDD) into your CI/CD pipelines. Here’s a structured guide on how to set it up effectively.
a. Tips for Integrating Gherkin with Test Plans and Suites in Azure DevOps
- Create Test Plans and Suites: In Azure DevOps, you can create test plans that correspond to your Gherkin features. Give each feature one or more test suites that contain related scenarios.
- Link Work Items: Link Gherkin scenarios to work items using tags, which improves traceability.
- Use Smart Docs: Document your Gherkins within Azure DevOps using Smart Docs. This is an MS Word-like tool, part of Modern Requirements4DevOps, natively integrated into ADO that helps maintain clarity on each scenario and keeps all stakeholders informed.
- Document Management System (DMS): You can upload, download, version, and folder Gherkins and other requirements documents in a variety of formats like PDF, Word etc. It helps create greater flexibility and communication within your organization, even for teams that don’t use Azure DevOps.
b. Use AI to Efficiently Create Gherkin in Azure DevOps
Copilot4DevOps is a groundbreaking AI requirements management solution that allows teams to generate high quality requirements from work item data in a single click. By using its AI capabilities, you can generate syntactically correct and semantically meaningful Gherkin.
Copilot4DevOps natively integrates into Azure DevOps and allows developers and QAs to focus on writing high quality Gherkin without getting bogged down by the intricacies of syntax.
You can also add custom instructions to further refine your output. This includes specifying the length, creativity, and language of your response.
5. Gherkin Examples and Use Cases
Gherkin is widely used in various industries to facilitate behavior-driven development (BDD) and improve communication between technical and non-technical stakeholders. Here are some real-world examples of who might use Gherkin and how they implement it
a. Software Development Teams
Software development teams use Gherkin to define user stories and acceptance criteria for their applications.
For instance, developers in a financial services company can write Gherkin scenarios to outline features like account creation, transaction processing, and user authentication. A Gherkin for Successful Account Creation can be as follows:
Feature: User Account Management
Scenario: Successful Account Creation
*Given the user is on the registration page
*When the user enters valid details
*Then the user account should be created successfully
b. Quality Assurance Teams
QA teams use Gherkin to automate user acceptance testing (UAT) for features. For an e-commerce company creating a shopping cart experience, an example of adding a product to cart might be:
Feature: Shopping Cart Functionality
Scenario: Adding a Product to the Cart
*Given the user is on the product page
*When the user clicks on “Add to Cart”
*Then the product should be added to the shopping cart
6. AI, Gherkin, and Azure DevOps
In software development, Gherkin within Azure DevOps enriches Behavior-Driven Development (BDD) by ensuring all team members—technical or not—comprehend project requirements clearly.
By mastering Gherkin in Azure DevOps, teams can enhance collaboration and drive higher project success rates. Adopting Gherkin is about improving software quality and integrating a shared language across your development lifecycle. By using Gherkin across your teams, you can transform your workflow, increase transparency, and achieve better outcomes in your software development projects.