“Why you need Cucumber for API testing?”

What is API testing?

Typically, API (Application Programming Interface) testing focuses on analyzing the app’s business logic, security, and data responses and is generally performed by making requests to one or more API endpoints and comparing the responses with expected results.

Performed manually or with automated testing tools, application program interface or API testing is used to check the API’s functionality and security levels to prevent a negative impact on its performance and reliability.

Why do we need API testing?

When using various websites, apps, and other software products, users want them to be secure, reliable, and free of errors. While there are any issues at the application programming interface layer, it can result in user-facing errors, slow performance, and damage your reputation. Here is why API testing can be useful:

• With application programming interface tests, QA teams can define how different software components interact and check if they work correctly.
• With application programming interface testing, teams can identify potential problems and make sure that the software will handle diverse conditions effectively.
• When it comes to potential software vulnerabilities, APIs can become a potential entry point for attackers. With application programming interface testing, testers can detect weaknesses in software to protect security and privacy.
• If any changes have been made, API testing prevents disruption to existing applications that use this API and helps maintain backward compatibility.

Types of Bugs Detected with Application Programming Interface Testing

Generally, during application programming interface testing we check the following:

• Data accuracy to verify that the data returned from an application programming interface aligns with expected formats, data types, etc.
• Missing or duplicate functionality to make sure that there are no repeated or missed features.
• Authorization or permission checks to verify the identity of a user/application that is requesting access to an API.
• Response time to reveal the duration of time required to process a request and return a response to the client
• Error codes in application programming interface responses to reveal whether the API request was successful or not.
• Reliability, performance, and security issues (checking how well the software performs, finding security problems, or issues like crashes and memory leaks).

Types of API Testing

Here are some of the common API testing examples with different types of tests based on which test cases can be created:

• Functional testing. With functional testing for APIs, you send requests to an API and validate that the correct responses are returned.
• Performance testing. With this type, you can verify that the application programming interface can handle large volumes of data and high traffic.
• Unit testing. As APIs have lots of small moving components, it’s effective to test them during the development phase and validate that each software module performs as designed.
• Integration testing. With integration testing, you can check if your application programming interface works well with different parts of your software, including web services, databases, or third-party applications. But you need to remember that opting for this type is essential if your application programming interface is complicated and not isolated from other components.
• Regression Testing. With this type, you can make sure that your application programming interface is still functional after an update or bug fixing has been performed.
• Security testing. This type of testing protects your API from data breaches, unauthorized access, and other security issues by systematically assessing the application programming interface for potential vulnerabilities and implementing measures to prevent or mitigate them.
• Load Testing. This type of testing helps test an API’s performance under high-user traffic to prevent slow response times, increased server load, and poor user experience.
• Stress Testing. With this testing type, you need to test an application programming interface with large data or sudden spikes in user requests.
• API Documentation Testing. With API document testing, testers make sure that application programming interface documentation is always up-to-date and correct while the API is set up and functions as documented.

What is Cucumber?

Written in Ruby, Cucumber is a BDD framework that allows teams to use a human-readable Gherkin syntax for writing test cases. When test scenarios are written in plain language, teammates without technical backgrounds can better communicate and easily understand what is going on in the project. Cucumber tests are linked to step definitions written in a programming language, which are then executed to verify the app’s behavior.

When using the Cucumber framework for API test automation, you can efficiently test the APIs to uncover any bugs or vulnerabilities before they become problems as well as save time and money in the long run.

Why use Cucumber framework for API testing?

• With Cucumber, teams can write test cases in plain English and avoid misunderstandings about what the tests are verifying.
• Cucumber can be integrated with various tools for application programming interface testing.
• Supporting BDD, teams can focus on the behavior of the application rather than the implementation details.
• Teams can reuse step definitions across different scenarios and maintain tests more easily.
• Thanks to Cucumber, teams can see what has been tested and what the results are.

API Testing Cucumber Your Steps to Follow

With API testing, teams can validate the business logic, data responses, and performance of server-side endpoints. When using the Cucumber BDD framework, testing teams can create tests written in Gherkin and make them understandable for the whole team. However, teams should understand the application programming interface specifications before writing tests. They need to overview the API’s purpose, functionality, endpoints, request methods, expected request formats, and response structures at the very start.

How to set up Playwright & Cucumber?

Prerequisites

On the begining you need to make sure you have the following in place:

A development environment with your preferred programming language (e.g., JavaScript, TypeScript, Python) installed.

node -v
npm -v

Step 1: Start a Project

From the very start, you need to initialize the Playwright project, which can be done by running the next command:

npm init playwright@latest

After that choose the programming language as Javascript when asked in the command line.

Next, you need to add project dependencies and establish configurations for test runners. Install Cucumber and REST Assured dependencies for application programming test interface.

npm i @cucumber/cucumber

Also, add the Cucumber extension to your VSCode:

Finally, you need to install the node-fetch library to your project using:

npm install node-fetch

Anyway, you can use any other HTTP library.

Step 2: Create Feature File

After you start the project and establish the appropriate configuration, it is imperative to create a structure so that your the feature files and step definitions will be well-organized for better clarity and understanding. Cucumber tests start with feature files, which describe the behavior of your application and when creating a feature file, you need to use Gherkin human-readable format with the following structure:

• Feature: it gives explanation to the feature that is going being tested.
• Scenario: it provides information about test scenario.
• Given: it describes the starting condition.
• When: it defines conditions.
• Then: it determines the expected outcome.

Here’s a Cucumber API testing example of a Feature file for the JS project:

Feature: Login User

  Scenario: Successful user login
    Given I send a POST request to the user endpoint with the following payload:
      | email                | password          |
      | jolir86609@ikaid.com | pass              |
    When the response status code should be 201
    Then the response body should contain "John Doe"

We have to create a feature folder and add our file to insert this code. After that add the path to this file and the steps file in vs.code =>settings.json Refer to the screenshot below for guidance:

Create a cucumber.json file and also add a path. It should look like this:

Step 3: Create Step Definition Directory

At this step, you can create a directory called step_definitions and add a JavaScript file (for example, login.js) Similarly, look at the structure of the file tree on top.

const { Given, When, Then } = require("@cucumber/cucumber");
const fetch = require("node-fetch");

Given("providing valid url", async function () {
    this.res = await fetch("https://app.testomat.io/api/login/", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
            email: "jolir86609@ikaid.com",
            password: "pass",
        }),
    });
});

When("the response status code should be 201", async function () {
    const status = this.res.status; // fetch returns status as a property
    if (status !== 201) {
        throw new Error(`Expected status code 201 but got ${status}`);
    }
});

Then("the response body should contain John Doe", async function () {
    const body = await this.res.json(); // fetch returns JSON via res.json()
    console.log(body);
    if (!JSON.stringify(body).includes("John Doe")) {
        throw new Error(`Response body does not contain 'John Doe'`);
    }
});

In the created file, you can implement the logic for each step defined in your feature file. Generally, step definitions are used to interpret Gherkin’s steps, execute actions like making API requests, and use assertions to validate API responses.

Step 4: Execute Tests

At this step, you can run your tests using the following command:

npx cucumber-js features

With this command, you can execute the tests defined in your Cucumber feature file and step definitions.

My test failed as the email is wrong, I know it. In addition, I checked this POST request with Postman also, you can see it better now.

Step 5: View Test Reports

To generate reports, you can integrate Cucumber’s built-in reporting features or use third-party tools like cucumber-html-reporter Based on test reports, you can get information about test coverage, success/failure rates, and potential areas of improvement.

Pay attention to the “format” settings in your cucumber.json file.

{
  "default": {
    "formateOptions":{
      "snippentInterface": "async-await"
    },
    "paths": [
      "tests/features/*.feature"
    ],
    "publishQuite": true,
    "dryRun": false,
    "require": [
      "tests/steps/*.js"
    ],
    "format": [
      "progress-bar",
      "html: cucumber-report.html"
    ]

  }
}

Cucumber Playwright Reporting with modern test management

Also, you can integrate test case management systems like testomat.io to get access to test results, metrics, and trends and quickly address any issues that arise during testing.

Push the Import button and just copy and paste the command in your CMD offered by TCMS to download your automated tests. By the way, it is a perfect option to sync your manual and automated tests in one place, consolidate Steps:

Similarly, with UI tips our test management suggests – launch a test execution of your Cucumber API Playwright framework.

Do not forget the recommendation to add a Playwright code runner plugin code to playwright.config.js file:

reporter: [
  ['list'],
  [
    '@Testomat.io/reporter/lib/adapter/playwright.js',
    {
      apiKey: process.env.TESTOMATIO,
    },
  ],
];

As a result, you can see such rich test result Report. It provides detailed insights into your test execution and comprehensive test run summaries, it ensures you have a clear view of your testing progress and quality metrics.

Best Practices for API Testing with Cucumber

• You need to remember that grouping your test cases by functionality is important. It will give you a better overview of the app status and improve maintainability.
• You can use mocking and stubbing techniques to simulate interactions with the application programming interface to isolate the application code from external dependencies and make the API testing process more efficient.
• You can apply hooks in Cucumber to set up preconditions and clean up post-conditions for test scenarios.
• You need to automate only what is not possible to be tested via unit or integration tests to avoid additional costs.

Bottom Line: What about using Cucumber test automation framework for Application Programming Interface (API)?

When you develop API-driven applications, you can use Cucumber for API testing. It offers a structured approach for writing human-readable feature files and linking them to step definitions. It helps teams create tests that are easy to understand and maintain.

There is no doubt that API testing is a critical part of the software development process. With Cucumber, you can make it more efficient and effective. By opting for Cucumber, you can deliver high-quality APIs and make sure that different app components function correctly.

If you have any questions, do not hesitate to contact our specialists for consultation!

The post Cucumber framework for API testing with Playwright example appeared first on testomat.io.

BDD advantages and disadvantages

Here are some advantages of using behavior-driven development (BDD) tests:

1. Improved communication: BDD tests are written in a natural language syntax called Gherkin, which makes them easy for non-technical stakeholders to understand. This can improve communication between developers and non-technical team members and ensure that everyone is on the same page about the desired behavior of the application.
2. Increased collaboration: BDD tests encourage collaboration between developers, testers, and business analysts, as everyone can contribute to the development of the tests. This can lead to a more holistic approach to testing and a better understanding of the business requirements.
3. More focused testing: BDD tests are designed to focus on the behavior of the application, rather than the implementation details. This can help ensure that the application is tested from the perspective of the end user and that the most important behaviors are covered.

Here are some disadvantages of using BDD tests:

1. Requires a learning curve: BDD tests use a new syntax (Gherkin) that may require a learning curve for those unfamiliar with it. This can be a barrier to adoption, especially for teams with limited time or resources.
2. Can be time-consuming: Writing BDD tests requires more upfront planning and collaboration than traditional testing approaches. This can be time-consuming and may not be practical for all projects.
3. May not be suitable for all projects: BDD tests are best suited for projects with well-defined business requirements and a clear understanding of the desired behavior of the application. If these conditions are not met, BDD tests may not be the most effective testing approach.
4. Limited tool support: While there are several tools available for automating BDD tests, the tool landscape is still evolving and may not offer the same level of support as more established testing frameworks.

Cucumber Tutorial

In this tutorial, we will go over how to set up a cucumber testing framework for end-to-end (E2E) or unit testing.

Summary:

1. Install Cucumber
2. Create a project directory
3. Initialize the project
4. Write your feature files
5. Write your step definitions
6. Run your tests

By following these steps, you will have a basic cucumber testing framework set up for E2E or unit testing. You can then continue to add more feature files and step definitions as needed to test different aspects of your application.

1. Install Cucumber: To use Cucumber, you will need to install it first. You can do this using a package manager like npm (for JavaScript) or gem (for Ruby).

   # npm 
   npm install cucumber 
   
   # gem 
   gem install cucumber

2. Create a project directory: Create a new directory for your project and navigate to it in your terminal.
3. Initialize the project: Initialize the project by running the following command:

   cucumber --init
   

   This will create the following directory structure:

   .
   ├── features
   │   ├── step_definitions
   │   └── support
   └── cucumber.yml
   

   The features directory is where you will store your cucumber feature files. The step_definitions directory is where you will store the implementation for your step definitions. The support directory is where you can store any additional support code for your tests. The cucumber.yml file is used to configure cucumber.

4. Write your feature files: Feature files are written in Gherkin, a natural language syntax for describing software behavior. Each feature file should describe a single feature or behavior of your application.Here is an example feature file for a login feature:

   Feature: Login
     As a user
     I want to be able to log in to the application
     So that I can access my account information
   
     Scenario: Successful login
       Given I am on the login page
       When I enter my username and password
       And I click the login button
       Then I should be taken to the dashboard page
   

5. Write your step definitions: Step definitions are the implementation for the steps in your feature files. They are written in a programming language like JavaScript or Ruby.Here is an example step definition file for the login feature:

   Given("I am on the login page", () => {
     // Navigate to the login page
   });
   
   When("I enter my username and password", () => {
     // Enter the username and password
   });
   
   When("I click the login button", () => {
     // Click the login button
   });
   
   Then("I should be taken to the dashboard page", () => {
     // Verify that the user is taken to the dashboard page
   });
   

6. Run your tests: To run your tests, use the following command:

   cucumber
   

   This will run all the feature files in the features directory. You can also specify a specific feature file or directory to run by passing it as an argument:

   cucumber features/login.feature
   

   That’s it! You now have a basic cucumber testing framework set up for E2E or unit testing. You can continue to add more feature files and step definitions as needed to test different aspects of your application.

BDD usage tips and tricks

By following these tips and tricks, you can help avoid problems with your BDD tests and ensure that they are effective at testing the behavior of your application:

1. Clearly define the behavior of the application: Before writing any BDD tests, it is important to have a clear understanding of the desired behavior of the application. This will help ensure that the tests are focused on the most important behaviors and will reduce the risk of writing tests that are not relevant to the business requirements.
2. Collaborate with all stakeholders: BDD tests are designed to be written by a cross-functional team, including developers, testers, and business analysts. Make sure to involve all relevant stakeholders in the test-writing process to ensure that the tests accurately reflect the business requirements.
3. Use a consistent syntax: BDD tests are written in a natural language syntax called Gherkin. Make sure to use a consistent syntax across all tests to ensure that they are easy to read and understand.
4. Keep the tests focused: BDD tests should focus on a single behavior or feature of the application. Avoid writing tests that cover multiple behaviors or features, as this can make them more difficult to understand and maintain.
5. Use clear and descriptive names: Use clear and descriptive names for your feature files, scenarios, and step definitions to make them easy to understand and maintain.
6. Regularly review and update your tests: As the application evolves, it is important to regularly review and update your BDD tests to ensure that they are still relevant and accurately reflect the desired behavior of the application.

Good BDD example

Some of the key characteristics of the good examples include:

1. Focus on a single behavior or feature: Each scenario focuses on a single behavior or feature of the application, which makes the test easier to understand and maintain.
2. Clear steps and verification points: The scenarios include clear steps and verification points to ensure that the behavior of the application is being tested effectively.
3. Use of descriptive and clear names: The feature files, scenarios, and step definitions have descriptive and clear names, which makes the test easy to understand and maintain.

Let’s take a look to a good gherkin test case. The next test covers three different behaviors of the shopping cart feature: adding an item to the cart, removing an item from the cart, and emptying the cart. It also includes multiple steps and verification points for each behavior, which makes the test more comprehensive.

Feature: Shopping cart
  As a shopper
  I want to be able to add and remove items from my shopping cart
  So that I can manage the items I want to purchase

Scenario: Add an item to the shopping cart
  Given I am on the product page for a shirt
  When I click the "add to cart" button
  And I select the size and quantity of the shirt
  And I click the "add to cart" button again
  Then I should see a notification that says "Shirt added to cart"
  And the shopping cart icon should show the correct number of items

Scenario: Remove an item from the shopping cart
  Given I am on the shopping cart page
  And there is at least one item in the cart
  When I click the "remove" button for an item
  Then I should see a notification that says "Item removed from cart"
  And the shopping cart icon should show the updated number of items
  And the item should no longer be listed in the shopping cart

Scenario: Empty the shopping cart
  Given I am on the shopping cart page
  And there are multiple items in the cart
  When I click the "empty cart" button
  Then I should see a notification that says "Shopping cart emptied"
  And the shopping cart icon should show 0 items
  And the shopping cart should be empty

BDD problems and bad examples

In this exercise, you will see examples of bad BDD tests for a shopping cart feature. These examples illustrate common mistakes that can occur when writing BDD tests and can help you understand what to avoid when writing your own tests.

Some of the problems with the bad examples include:

1. Lack of focus: The scenarios are too general and do not focus on a single behavior or feature of the application.
2. Lack of steps and verification points: The scenarios do not include enough steps and verification points to test the behavior of the application.
3. Combining multiple behaviors into a single scenario: This can make the test more difficult to understand and maintain.

By comparing the bad examples to good examples of BDD tests, you can see the importance of writing clear, focused, and comprehensive tests that accurately reflect the desired behavior of the application.

The next test is bad because it combines multiple behaviors into a single scenario (“Add and remove items from the shopping cart”). This makes it difficult to understand what is being tested and makes the test more prone to errors. Additionally, the test does not include any verification points to ensure that the shopping cart is being updated correctly.

Feature: Shopping cart
  As a shopper
  I want to be able to use my shopping cart

Scenario: Add and remove items from the shopping cart
  Given I am on the shopping cart page
  When I click the "add to cart" button for an item
  And I click the "remove" button for the same item
  Then I should see a notification that says "Item added to cart"
  And I should see a notification that says "Item removed from cart"

Scenario: Checkout
  Given I am on the shopping cart page
  When I click the "checkout" button
  Then I should be taken to the checkout page

Scenario: Empty the shopping cart
  Given I am on the shopping cart page
  When I click the "empty cart" button
  Then I should see a notification that says "Shopping cart emptied"

The next test is bad because it does not clearly define the behavior of the shopping cart feature. The scenarios are too general and do not specify the steps or verification points necessary to test the feature. Additionally, the test only covers a limited number of behaviors, which means that the shopping cart feature is not being tested comprehensively.

Feature: Shopping cart
  As a shopper
  I want to be able to use my shopping cart

Scenario: Add an item to the shopping cart
  Given I am on the product page
  When I click the "add to cart" button
  Then I should see a notification

Scenario: Remove an item from the shopping cart
  Given I am on the shopping cart page
  When I click the "remove" button for an item
  Then I should see a notification

Scenario: Checkout
  Given I am on the shopping cart page
  When I click the "checkout" button
  Then I should be taken to the checkout page

Summary

BDD is a powerful tool for improving communication and collaboration within a development team, as it allows non-technical stakeholders to contribute to the testing process. In this exercise, we have covered the basics of BDD and provided examples of good and bad BDD tests. By following best practices and learning about advanced features and tools, you can continue to improve skills in the BDD approach.

What to learn or to do next? That is your learning curve:

1. Learn about advanced Gherkin syntax: Gherkin is the natural language syntax used to write BDD tests. There are advanced features of Gherkin, such as scenario outlines and data tables, that can help you write more efficient and flexible tests.
2. Explore different BDD tools: There are several tools available for automating BDD tests, such as Cucumber, Behat, and SpecFlow. Explore different tools and choose the one that best fits your needs and workflow.
3. Understand the role of BDD in the development process: BDD is not just a testing approach, but a philosophy that can be applied throughout the development process. Understand how BDD fits into your development workflow and how it can be used to improve communication and collaboration within your team.
4. Learn about other testing approaches: In addition to BDD, there are other testing approaches that can be useful, such as test-driven development (TDD) and acceptance test-driven development (ATDD). Understanding the strengths and weaknesses of different testing approaches can help you choose the right approach for your project.
5. Keep up to date with industry trends: The field of software testing is constantly evolving. Stay up to date with industry trends and best practices by reading blogs and attending conferences and workshops. This will help you stay current and improve your skills as a senior-level engineer.

The post Mastering Cucumber: A Step-by-Step Guide to Setting up an Gherkin E2E tests appeared first on testomat.io.

What is Cucumber?

Cucumber is a behavior-driven development (BDD) framework written in Ruby that supports behavior-driven development, a behavior-based software development methodology. It uses the easily readable English language – Gherkin – to write test scripts for user requirements. The Cucumber framework facilitates clear and concise documentation of software behaviors, which can be understood by all stakeholders, including non-technical team members.

The advantage of this approach is that Gherkin syntax is understandable to all team members, including specialists without technical knowledge, such as Product Owners (PO) or Business Analysts (BA). This meets one of the basic needs of modern Agile teams – technical and business team collaboration during the testing and development process of digital solutions. Moreover, the integration of Cucumber testing within Agile methodologies enhances the communication between developers and business stakeholders, ensuring that software functionalities align closely with business requirements. Additionally, the Cucumber framework effectively aligns technical implementation with business objectives, ensuring that all team members understand the features and behaviors of the software under development.

Automation Testing With Cucumber Framework

The essence of the BDD approach is that test scripts and acceptance tests should be written before coding begins.This allows testing to be done more efficiently than if it were performed during the software release stage.

Behavior-driven development (BDD) scenarios in the Cucumber framework involve using the Given-When-Then structure to write test scenarios. This sequence helps to describe the system’s behavior from the user’s perspective.

Let’s consider an example of such a scenario for testing the login functionality of a web application:

Feature: Login

  I want to login on a website

  Background:
    Given I go to '/login'
    And the field 'email' is empty
    And the field 'password' is empty

  Scenario: Error on empty fields
    When I click on 'enter'
    Then field 'email' should be with error
    And field 'password' should be with error

  Scenario: Wrong password
    When I enter incorrect ‘username’ AND ‘password’ values
    And I click on 'enter'
    Then I should see 'E-mail or password is incorrect’

  Scenario: Login successfully
    When I enter correct ‘username’ AND ‘password’ values
    And I click on 'enter'
    Then I am directed to the homepage

Your team can also try implement this approach in your Agile SDLC(Software development lyfe cycle), the benefits of Cucumber for testing and programming will be appreciated by all ones. Incorporating cucumber testing into your Agile SDLC not only streamlines the testing process but also ensures that the software development aligns with user expectations and behavior scenarios.

Why Do Many QA Teams Choose Cucumber?

We have tried to highlight the key benefits of test automation with Cucumber:

1. The software requirements are formulated in simple English text format. As we mentioned earlier, Cucumber framework uses the Gherkin syntax to write test scripts, which is understandable to all team members, including every non-technical user.
2. Support for multiple programming languages. Unlike many other frameworks that support a single language, the Cucumber testing tool supports Ruby, Java, JavaScript, Scala, Perl, and other programming languages. This allows you to write code along with Cucumber framework in your preferred language without worrying about whether or not you can use the framework. The versatility of Cucumber in supporting various languages makes it an ideal tool for behavior-driven development, as it accommodates a wide range of technical environments and team skills.
3. Written code can be reused. All Cucumber feature files contain clearly structured Given When Then test scenarios. This makes it easier to reuse the code, speed up the software testing process, and get the finished software product to market. Furthermore, the integration of cucumber testing with other tools and frameworks in the development pipeline can further streamline and optimize the entire software testing lifecycle. The reusability of code in Cucumber is especially beneficial in the context of behavior-driven development (BDD), where similar user scenarios may recur across different features or applications.

Cucumber Testing Tools Uses by QA Teams

Popular frameworks like Playwright, Selenium, Cypress, Serenity, TestNG and JUnit for Java-based projects, Appium for mobile testing allow the automation of Cucumber scenarious. Additionally, Cucumber testing tools like testomat.io, BrowserStack, LambdaTest, TestRail — provide advanced reporting, test management, integration with CI\CD and third-party tools like Jira, making Cucumber testing more efficient and scalable. Choosing the right combination of tools ensures the implementation of a smooth automation strategy and deep collaboration between developers and testers.

Recommend topics:

• Top BDD Testing Tools for Better Communication and Premium Product Quality
• 19 Best Report Testing Tools in 2025 Comprehensive List
• Cucumber framework for API testing with Playwright example
• How to create readable End-to-End tests with Cypress and Cucumber

Sync Cucumber Tests With Manual Testing

We consider the needs of modern Agile teams who choose to work with the BDD framework Cucumber, so we implemented the possibility of integration with automated tests written with Cucumber in our TMS. This integration is based on the Three Amigos approach, meet more detail: What are 3 Amigos in Agile? by following the link to the article on our Blog.

Synchronization makes BDD tests available to all team members and allows them to work together on the project. See below how it works step by step.

Getting Started Cucumber Testing From Example (ready boilerplate)

Our TMS is a Cucumber testing tool, we mentioned it on top. It supports integration with the most popular software testing frameworks, including WebdriverIO, Playwright, Protractor, TestCafe, CodeceptJS, Codeception, and Jira project management system in the next combination with Cucumber framework:

• Cucumber
• Cypress+BDD
• Playwtight+BDD
• WebdriverIO+BDD
• CodeceptJS+BDD
• Codeception+BDD
• TestCafe+BDD
• Java+BDD works through JUnit XML reporter
• etc.

So, our Cucumber testing tool is completely flexible, as you may see. This tutorial has all the information you need to work with BDD successfully. Particularly for cucumber testing, our platform ensures seamless integration and execution, providing an efficient way to manage and run your BDD scenarios. Below we will focus on the Cucumber sample. If you use another tool, change the testing tool you need.

#1 Create A New Test Project

Create a new project in TMS in one click if you have ready test automation framework already, like in the picture. You should choose the BDD option for the BDD project logically.

After that import the Feature File. To do this, go into the project dashboard and select the Import Project from the Source Code menu item.

#2 Generate API Key And Import Autotests

Select the framework and project language. TCMS recognizes your laptop OS and generates a command with API key according to it. You should copy this command and execute it on CMD. This one uploads your Cucumber tests from the source code to test management.

End your importing by pressing the Finish button. At the same time, look at the console, how the importer is analyzing code accurately and displaying the number of founded tests in the test framework.

If you enter your project, you will see these tests. You can view their structure by expanding the tree. You may enter your suites and check test cases inside on the bird’s eye.

In addition to importing an existing feature file, you can create a new manual test case. To do this, select the Create Suite menu item, and in the window that opens – Create Test. You can create tests one at a time or use the Bulk function and write all the tests you need at once.

If you copy test case from the code editor, as I did, you can auto-format it to bring it a tidy appearance.

In writing manual test cases, users of our TMS are helped by another feature – Intelligent auto-complete steps. After the feature file is synchronized, all existing steps in it are automatically added to the Steps database. This is very convenient because when writing new test cases, they can be reused by selecting them from the open list.

#3 Organize your Cucumber tests in the best way

If you need to structure test cases, you can reorder them or use Bulk Action, which allows you to reorder tests, create new test suites, move test cases to another test suite, or delete certain tests.

With Project Timeline, or Pulse, you can analyze all the changes you have made to your project. You can see what was changed, by which user, and when, and, if necessary, undo the wrong action with the Rollback or Restore to Previous Version button. Moreover, this functionality proves particularly useful in cucumber testing, where tracking the evolution of test scenarios and their outcomes is crucial for continuous improvement in BDD practices.

#4 How Do I Create A Report In Cucumber Framework?

For Cucumber framework, as for others, there is a Reporter, which must be installed in your test project. Just copy and paste this command into your command line.

After that, you can run a test run.

During the test run, you will have access to a real-time results report. You will see detailed information about what went wrong if any tests failed. Here you can also see the script code, existing attachments, etc.

If you run a manual test, you can also get a report on its results. You have the opportunity to view the status of each test case or to examine all the details: check what failed. You can also filter the results you want.

Thus, testomat.io test management allows you to control the performance of manual and automated tests in one place.

The TMS provides additional functions for user convenience. One of them is rich Analytics for your Cucumber testing framework:

In-depth analytics, based on detailed reports of test results, are available on the Project level as well as the Global level (implemented to satisfy QA managers’ needs). Thanks to this feature, you can track test coverage and check if the project has flaky tests, slow tests, ever-failing tests, etc.

Running Cucumber Test On CI\CD

You can set up the CI\CD pipeline and run all or individual Cucumber tests. Testomat.io supports seamless integration with popular CI\CD tools: GitHub, GitLab, Jenkins, Bamboo, and CircleCI. This enables continuous testing, real-time reporting, and notifications at every stage of the software testing lifecycle. Especially for cucumber testing, this integration facilitates the execution of BDD scenarios in a continuous integration environment, enhancing the efficiency and effectiveness of your testing strategies.

One key thing that you must decide is: in which way do you want to manage the Cucumber scenarios? Do you want to use TMS or Advanced Jira Plugin directly? The Jira plugin allows you to do everything you do in the test management system. All actions are synced between them. between It was done in order to involve non-technical specialists in the technical part of the software testing process.

Comparison table: Cucumber VS Playwright VS TestCafe

We hope you were able to learn a lot of useful information from this Cucumber framework tutorial and take advantage of the integration features that are implemented in our TMS. Namely, on How to organize your Cucumber tests and get a reach report and analytics in a simple way.

The content is available also in video format if you convenient reproduce the steps to visualize your tests and get an informative report by watching.

The post Cucumber Testing Tutorial: Organize Your E2E or Unit Framework appeared first on testomat.io.

The first ones say that: BDD “does not work!”, “There is no need for BDD!” and “Cucumber with BDD just adds redundant abstractions and layers!”.

The second part usually responds: “You are misusing BDD!” “It works for us!”. It turns out that the answer is just in the middle: each party is correct in some way.

Also read to this subject:

• BDD & Agile Methodologies in Quality Assurance
• Writing BDD Test Cases in agile software development
• What are Three amigos in Agile?

I have used BDD automation tools on various projects. At first, it was Specflow (C#), then there were Cucumber + BDD (Java, Scala), Thucydides (Serenity) + JBehave, built-in BDD in Rest Assured, Gauge (Java).

In addition to those I have listed, many more tools and wrappers use BDD approaches in different programming languages ​​and platforms.

Why do many engineers not like this word – BDD? Let’s figure it out. All coincidences with real people and projects, please consider fiction. Of course, everything is different in your project, and BDD works. If such – please share your thoughts in the comments.

How is BDD sold to the customer?

Yep, in many cases, BDD seems like a “magic pill” that helps any team:

• The whole team follows the BDD paradigm (when a 3-amigo meeting gathers – and the tester, developer, and business analyst write these very “sacred” scenarios that are understandable to everyone. And this happens for each task in the product backlog);
• Managers and the customer can write business scenarios by themselves;
• The customer and other business owners can read the test reports and understand what was tested and what wasn’t;
• Testers can write scenarios very fast and then automate them;
• All team members can understand BDD tests, in particular, Cucumber BDD pair and contribute new ones (even developers and DevOps engineers – everybody!);
• The test team can get nice, beautiful reports out-of-the-box (hello, Serenity)!
• Automation engineers can easily change the test framework and leave the scenarios unchanged!

What is happening in the real world*?

*By the real world, I mean a typical big project in an outsourcing/outstaffing company.

1. The communication chain becomes longer when there are oceans and timezones between development and business teams. But those teams need to deliver value and new features fast. BDD process either does not start working at all or fades as time goes on. A tester (or some invited Agile coach) may try to fan this ember, but the reality is usually cruel.
2. If the team starts the BDD process, then, after a few months, the burden of writing and supporting Gherkin scenarios will be on the shoulders of the test engineer. As a result, the test engineer either plays an endless “ping-pong” with the business owner to clarify requirements or writes the scenarios by themself. When a tester asks to review the scripts, the usual answer from the business owner is: “I’m ok, let’s deliver!”.
3. The company hires separate automation engineers if the tester does not have sufficient skills to write scripts and automation tests for them. The task of an automation engineer will be just the transformation of these exact scenarios into autotests. (Hello, routine!)
4. The customer looks at the results of autotests and reports for some time. Maybe even praises how everything is clear. But over time, the only thing that becomes important to the business owner is what risks exist for the release. Nobody except the tester and QA Manager checks this lovely report.
5. An automation engineer quickly realizes that the Cucumber with BDD layer only adds more “pain” to support. Scenarios grow and become monstrous panels of 30+ steps. It seems like you want to reuse the steps, but it’s not so easy. The automation engineer suffers (and polishes his CV in the meantime). Outside – there are many other projects without pain Cucumber and BDD.
6. As a result, the number of scenarios exceeds conceivable and inconceivable limits. It becomes difficult to support them. The customer has already forgotten that the scripts are in text format. The only thing the customer cares about is fast feedback about risks for a particular release.
7. When patience runs out – a magical team of senior experts comes in who quickly rewrite all this but using a simple and convenient code without BDD. These tests also run in parallel (locally or in the clouds)
8. The customer is happy. The team rejoices. Management opens the champagne!
9. And only somewhere in another company, the gray-haired automation engineer continues to flinch at the sounds – “Given, When, Then…”

Is BDD so bad? Maybe we are “cooking” it wrong?

There are some successful cases!

Many product companies successfully use the BDD approach, including Cucumber + BDD. So the teams are small, in one location. Business is interested in understandable scenarios.

If something is not clear to the testers, he will go and quickly “pull” the analyst to the next room and clarify the details.

Management looks at the reports’ details and thinks about each feature’s business scenarios. In the JIRA ticket, the description goes immediately in the Gherkin format.

Not only Gherkin!

Some other tools on the market provide the same abstraction as Cucumber but do not impose restrictions in the form of Given-When-Then. For example, the Gauge framework. With Gauge, you can write your tests in the free format. You can even store test cases as Markdown files and upload them to TMS as needed.

The text can be helpful!

In some cases, an additional text layer with a data-driven approach can benefit the team greatly. Test engineers can easily add new tests by changing only a few lines of code. These scenarios can be executed on multiple different platforms and browsers.

So is BDD good or bad?

The best answer is – it depends!

It depends on the way how you use the tool.
It depends on how the team works with BDD approaches.
It depends on whether you can admit that BDD is useless for your project and discard it in favor of another tool or framework.
It depends on whether you can apply an engineering approach to the testing or continue to suffer.

What do you think about BDD?

You may find Oleksandr by contact on the top and discuss the topic more closely as well

The post Are Cucumber with BDD useful in <br>a test engineer’s diet? appeared first on testomat.io.