Typed E2E test IDs

tl;dr – Improving the DX when writing E2E tests by using typed test IDs.

Utilizing TypeScript to create typed test IDs
Sharing test IDs between the frontend and the test suite:

// app/page.tsx
<h1 {…e2e.home_heading}>
Welcome
</h1>

// tests/home.spec.ts
const heading = page.getByTestId(e2e.home_heading.id);

Full example

When writing E2E tests, it is common to use test IDs to select elements on the page. This is especially useful when the element does not have a unique selector or when the selector is likely to change. However, hardcoding test IDs in place can lead to errors and make the test suite harder to maintain. In this post, I will present a pattern that allows you to share test IDs between the frontend and the test suite, and how to utilize TypeScript to create typed test IDs.

We start with a project that was bootstrapped with npx create-next-app. For the E2E test we use Playwright and set it up as described in the testing guide provided by Next.js.

Getting started

We start by simplifying the bootstrapped Next.js project, so that we have a single page left:

and write a simple E2E test for it:

This test is straightforward and checks if the heading is visible. The selector (‘h1’) for the heading is as simple as it gets but in a real-world application it is likely that we need to select elements in a more reliable way.

We can start by adding a test ID to the heading:

and update the test to use the test ID:

This is a huge improvement. The structure of the page can change now without breaking the test.

A straight forward approach

We can take the previous approach a step further by sharing the test ID between the frontend and the test suite. For this we create a file e2e.ts and define a object containing the test IDs:

and import the test IDs in the page and in the test:

This alone already improves the DX and the maintainability of the test suite as we now have a single source of truth for the test IDs. The only thing we would have to remember when using this approach is the name of the data attribute data-testid and it would be nice if this is not the case.

Typed test IDs

Instead of setting the data attribute directly we could also pass it by spreading a corresponding object, for instance:

Now, extending on that idea we can improve our previously defined e2e object:

Breaking it down, we define a dataAttribute and an array of attributes in a single location. Each attribute is then mapped to an Attribute class which enables us to spread the test ID in a component and, at the same time, comfortably access the test ID in the test suite. With the use of this approach our final test setup looks like this:

Noteworthy is that we can safely spread the Attribute object in the component since spread only copies enumerable own properties, this means the id getter will have no effect on the component.