Native Steps Implementation for Enhanced Test Architecture in Cypress

[yuri-pires]

What would you like?

I would like to apply a "steps" approach in my code to group similar functionalities, whether they are validations, selectors, or Custom Commands, to achieve better architecture for large-scale projects and better visualization in the Test Runner Report and CLI Reporter.

Reflecting on this, I believe that a "steps" approach or something similar could reduce one of the biggest pains in the QA engineering community for large projects:

• Cucumber: Many companies require QA engineers to use Cucumber for writing automated tests, with the argument that this "will make it easier for non-technical people to follow the tests." However, in practice, this usually results in a lot of text files and extra hours of typing, which, in the end, no one reads. This approach breaks the revolutionary simplicity that Cypress brought to the automation tools market by not offering a native solution for teams using BDD as a development methodology and wanting to reflect these behaviors technically in the code.

Why is this needed?

Show me the code

Just as it's difficult to create a recipe from scratch and get it right on the first try, here is a "recipe" that came to my mind. If properly developed by the Cypress team, it could become a future improvement or serve as a foundation for a more refined technical analysis of this idea.

Take a look at this draft—it seems simple, right?

// I am a test suite
describe('Login Test', () => {
  // I am a test case
  it('Should allow the user to log in with valid credentials', () => {
    // I am the first step, equivalent to the "Given" in Cucumber
    cy.step('User enters valid credentials', () => {
      cy.get('input[name="username"]').type("username");
      cy.get('input[name="password"]').type("password");
    });
    
    // I would be the "When"
    cy.step('User clicks the login button', () => {
      cy.get('button[type="submit"]').click();
    });
    
    // And I would be the "Then"
    cy.step('User sees the welcome message', () => {
      cy.contains('Welcome').should('be.visible');
    });
  });
});

Yes, it’s quite simple, as the question above suggests. However, imagine a complex project. Even when creating a Custom Command to encapsulate the action of successfully logging in, we might still have additional steps. This approach would offer a cleaner code organization if a QA engineer opts for this model.

Results of This Implementation

With this implementation, we will eliminate the need for Cucumber and take a step forward for Cypress to become the pinnacle of simplicity and efficiency in automated testing, just as Go is in backend development with its 100% native functionalities.

Imagine this: when we use steps, we want to see those results grouped in a report that follows the title we assigned to each step, right? With that in mind, I created a draft of this report:

=================================
       Cypress Test Report
=================================

Test Suite: Login Test
  ✓ Should allow the user to log in with valid credentials (350ms)

    Step 1: User enters valid credentials  ✔ (100ms)
    Step 2: User clicks the login button   ✔ (150ms)
    Step 3: User sees the welcome message  ✔ (100ms)

---------------------------------
Total: 1 Test, 3 Steps
Passed: 1 Test, 3 Steps
Failed: 0
Skipped: 0
Duration: 350ms

=================================

Report Explanation

• Test Suite and Test Case: The report starts by identifying the test suite and the specific test case, similar to how it is usually done in Cypress.

• Detailed Steps: Each step within the test is listed with a descriptive name, execution time, and status (✔ for success, ✖ for failure). This allows for a more detailed tracking of the test flow and makes it easier to pinpoint issues.

• Final Summary: A final summary provides the total number of tests and steps executed, how many passed, failed, or were skipped, and the total execution time.

Advantages of the Detailed Step-by-Step Report

• Easier Debugging: If a specific step fails, it’s easier to identify exactly where and why the failure occurred.
• Greater Transparency: Non-technical stakeholders can easily follow the flow of tests, understanding what is being validated at each step.
• Team Efficiency: QA engineers can quickly see which parts of the test process are slower or where failures occur, allowing for targeted optimizations.

What Now?

Well, since I couldn't think of all the ingredients for this recipe, I’ll leave it to the new "chefs" who read this to find a way to adapt it to the Browser Test Runner and to test reports like Allure and Mocha. By integrating these reports and making some improvements, we will take a big step forward in enhancing this beloved tool 💚

Other

No response

[fenesco]

Something similar was created by Filipe Hric in the past, it would be very interesting to incorporate into Cypress.

cypress-plugin-steps