E2E testing

What is an E2E test?

The most effective way to ensure that a web application works properly is by doing manual testing: follow the steps according to a test plan, how a final user will interact with the web site. E2E testing will allow us to replicate the manual steps in an automated way and can be added as part of a continuous integration environment.

When should we create an E2E?

We should create E2E tests whenever we need to replicate the steps of a manual test case on a web site such as a final user will do it, to secure the correct functionality. Also, when we need to validate styles and other html properties of components dynamically, we can do it with E2E tests.

Structure

Commands: Cypress commands are methods of the cy namespace object. Usually, we use commands to map UI elements to be reachable from an automated script. For example, in this case we need to map a button element of the web site.
Using the Selector will allow us to map the UI element and use it during the run of our script.
The way we use that selector in our tests is using the get method from our cy object which is going to return the first element that matches with the selector. Then we can assign a constant with the result of invoking our method to do operations such as clicks, asserts or validations.
Specs: A file of tests is called spec, which have a describe method that is a test suite and each it inside is one different test. This is the structure of the spec files.
We can have hooks for different actions according to a specific moment in our test execution, for example if we need to visit a specific site before running our tests, we can do it with the before hook:
Please check this site for more information about cypress hooks: Cypress - Hooks (tutorialspoint.com)

Best practices.

A regular issue with selectors is that if we try to do our E2E tests when the application is built, some selectors may change, for this reason we can add an additional attribute to the HTML elements that we need to use in our command methods, for example:
Recomended
Not recomended
cy.get(‘[data-cy=submit]’).click();
cy.get('button’).click();
With this practice, we secure that our commands are isolated from future changes in our application, letting them to work properly.
Another issue that we can found is by adding unnecessary wait instructions. If we are waiting for a button to be visible, we must use the should instruction, which is an assertion that automatically will retry its execution until is pass or time out, instead of using an explicit wait.
Recomended
Not recomended
cy.get('button’).should('be.visible');
cy.wait(3000); expect(btn1()).to.be.visible();
For more practices, please check this site: Cypress Best Practices - DEV Community
Copy link
On this page
What is an E2E test?
When should we create an E2E?
Structure
Best practices.