End-to-End Testing

In this chapter, we will look at how to create an End-to-End (E2E) test suite for a Vue.js application with Cypress. In order to write robust tests, we’ll look at common pitfalls and best practices, such as intercepting HTTP requests and waiting for elements to appear without timeouts.

As we proceed, you will gain an understanding of E2E testing and its use cases. You will see how Cypress can be configured to test a Vue.js application and also interact with and inspect a User Interface (UI) using it. Throughout the chapter, you will gain familiarity with the pitfalls of arbitrary timeouts and how to avoid them with Cypress’ waiting functionality.

Toward the end of the chapter, you will also learn when, why, and how to intercept HTTP requests with Cypress.

In this chapter, we will cover the following topics:

• Understanding E2E testing and its use cases
• Configuring Cypress for a Vue.js application
• Using Cypress to interact with...

Technical requirements

There are no technical requirements for this chapter beyond the git CLI, which you will have already used by now. You can find this chapter’s source here: https://github.com/PacktPublishing/Frontend-Development-Projects-with-Vue.js-3/tree/v2-edition/Chapter12

Understanding E2E testing and its use cases

Most developers will have seen a version of the testing pyramid shown in the following figure:

Figure 12.1 – A diagram of the testing pyramid

E2E tests fall under the UI testing category. The type of test we’ll be looking at in this chapter is automated E2E tests using Cypress.

E2E and UI tests provide a level of confidence higher than unit or integration tests. They’re testing the application as used by the end user. The end user doesn’t care why or where a bug is happening, just that there is a bug.

The where and why of a bug tends to be the concern of unit and system-level tests. Unit and system-level tests check that the internals of a system work as the specification or code describes them. UI-level tests validate that application flows are working as expected.

A strong E2E test suite that runs quickly, has few false negatives (where a test fails but the application works...

Configuring Cypress for a Vue.js application

Cypress is a JavaScript E2E testing framework. It’s designed to solve the very specific need of writing E2E tests using JavaScript. This is in contrast to other full-fledged browser automation solutions, such as WebdriverIO (https://webdriver.io/), Selenium WebDriver (https://www.selenium.dev/), Puppeteer (https://developers.google.com/web/tools/puppeteer/), and Playwright (https://github.com/microsoft/playwright), which are commonly used to write E2E tests.

The big difference with Cypress compared to these other solutions is its singular focus on writing E2E tests (as opposed to generic browser automation). Tests can only be written using JavaScript (Selenium supports other languages), and require Chrome, Edge, or Firefox (WebKit support is in development).

Cypress has a Graphical User Interface (GUI) to run and debug tests locally and comes with built-in assertion and stubbing/mocking libraries.

To add Cypress to a new...

Using Cypress to interact with and inspect a Vue.js UI

In order to E2E test a new application, Commentator Pro, we should start by adding something to test. In this case, we’ll have a heading (h2) with the name of the application. In the App.vue file, we’ll have the following code:

<template>
<h2>Commentator Pro</h2>
</template>

In order to test this with Cypress, we can change the cypress/e2e/example.cy.js file with the following code. We’ll go to the running application using cy.visit('/') and then check that the h2 on the page contains Commentator Pro using cy.contains('h2', 'Commentator Pro'). The cy.contains function is overloaded and can be used with one parameter (the text to match against) or two parameters (the selector for the container and the text to match against):

describe('Commentator Pro', () => {
  it('Has a h2 with "Commentator Pro"', () ...

Triggering and waiting for UI updates with Cypress

The tests we’ve written up until now are quite simple and only check that the application isn’t crashing on load in the browser.

One of the strengths of E2E tests is testing that the UI behaves as expected when a user interacts with it with high fidelity. We’ll use Cypress’ selection (the .get() function), event triggering (the .click() function), and assertion (the .should() function) functionality to test a Vue.js application in this section.

Cypress’ automatic retries on DOM selection will allow us to write E2E tests without explicit wait or timeout conditions. Waits and timeouts are a staple of other E2E testing systems and tend to be a source of flakiness in tests.

To begin with, we will add a comment editor to our Commentator Pro application. Displaying the editor (a simple textarea) will be toggled by clicking on the Add a New Comment button.

In order to keep writing tests without...

Intercepting HTTP requests

As mentioned in previous sections, Cypress is designed as a JavaScript E2E testing solution. This means that it comes with built-ins such as assertions, automatic wait/retries, sane defaults for running the application, and extensive mocking functionality.

HTTP requests can be slow and tend to introduce flaky behavior into tests. What’s meant by flaky is intermittent false negatives – that is, failures that are not caused by an application issue but rather by connectivity issues (for example, between the server running the tests and the backend hosts).

We would also be testing the implementation of the backend system. When using Continuous Integration (CI), this would mean having to run the backend systems in whichever CI pipeline step needs to run E2E tests.

Usually, when the backend requests are intercepted and a mock response is sent, we also say that the HTTP requests are stubbed in order to avoid tests flaking (meaning intermittent...

Summary

Throughout this chapter, we’ve looked at leveraging Cypress to test Vue.js applications E2E. E2E tests in general are useful to give us a high level of confidence that tested flows will work as expected, as opposed to unit or integration tests, which validate that our code works as expected at a much lower overhead.

We’ve seen how to use Cypress to inspect, interact with, and assert against a UI. We’ve also shown how Cypress’ default wait/retry functionality is a great advantage when writing robust tests. We leveraged Cypress’ HTTP interception library to stub out HTTP requests and make tests more predictable and faster.

Finally, we looked at how to set up visual regression testing with Cypress. In the next chapter, we’ll look at how to deploy a Vue.js application to the web.