How to set up BDD User-centric E2E tests

In this article, we will see how to set up relevant and effortless end-to-end tests for your web application

The problem ?

End-to-End (E2E) testing for web application, is a comprehensive testing approach that aims to validate the functionality, performance, and reliability of a software system as a whole, simulating real-world user scenarios.

But if the generally recommended approach is to try to reproduce credible user scenarios, most of the popular tools (like Cypress and Playwright) invite to express these scenarios as development files (js, java, etc).

Using development language allows to write rich and advanced e2e test, but requires to translate our user scenarios into source code with the risk of corruption.

Therefore, it’s better to use BDD to express your scenarios. With Bdd, you write End-to-End tests in a natural language, which broadens the audience that can read and use them. This means your Product Management and Customer Success teams can read and comment on your tests without knowing any programming language.

Here’s an example of a BDD test written in Gherkin:

Feature: Login functionality
  As a usevbr
  I want to be able to log into the system
  So that I can access my account

  Scenario: Successful login
    Given I am on the login page
    When I enter valid credentials
    And I click the "Login" button
    Then I should be redirected to the home page
    And I should see a welcome message

Cucumber is the most popular testing framework for writing BDD test in Gherkin. Cucumber reads the Gherkin feature (usually stored in .feature files) and executes each step in the test.

But, and this is the big problem, you have to code your own step definition.

If it remains priomodial to create step definitions that are specific to your web application, writing step definitions for generic actions like checking the presence of a content in the dom, typing a text in a field or clicking on a button can be considered as boilerplate code in the same way that getter and setter were in java 8.

Just don’t do it, use @uuv

A solution

@uuv is a solution that helps you write user-centric end-to-end tests effortlessly by relying on a set of known tools such as cucumber, axe-core, cypress or playwright.

How to use it ?

• Simply choose between @uuv/cypress or @uuv/playwright then install it with npm

• Write your first test, create the file uuv/e2e/first-test.feature in the project root with the following content :
  

Feature: Hello World
Scenario: Search - Successful case
  When I visit path "/"
  Then I should see an element with role "heading" and name "My app title"

You can find test examples here : weather-app.feature

• Run your tests :

# browser mode
npx uuv open
# or for headless mode
npx uuv e2e

Benefits of using uuv

• User-centric approach : your tests resemble the way your software is used
• If used correctly, integrates **accessibility **from the development stage
• A living documentation is possible because we propose an unified language for developers and non-developers with a rich dictionary of ready-to-use sentences
• A Wizard(@uuv/assistant) that facilitates the writing of tests by suggesting the most accessible sentences
• Integrates several runtime engines : @uuv/cypress or @uuv/playwright
• User friendly and standardized execution report