My experience writing automated tests for a SPA

In recent times, the author has created an impressive test suite for the Réécoute single-page application (SPA), which they will discuss in this article. Réécoute is an audio player optimized for lengthy recordings, with various interactive features that rely on client-side JavaScript communicating with a single server via JSON over HTTP. The complexity is divided equally between the backend and client-side JavaScript.

To test the app, the author opted to use Playwright, running it against a real web browser. The test suite consists of approximately 20 files, each containing 1-4 test cases. The author prefers lengthy test cases that describe full user journeys, rather than small tests for individual steps. They write tests as they would use the app in production, creating their own objects without relying on existing data or cleaning up anything. Data accumulates, which works well for non-public applications like Réécoute.

The author uses helper functions to create data (createUser, createBand, createSession, etc.), avoiding before/after hooks. While browser automation is slower than parsing HTTP response bodies, with Réécoute, parallelism was enabled, allowing tests within the same file to run concurrently. The Playwright suite finishes in just over 20 seconds on the author's MacBook Air.

Playwright supports all major web browsers and runs tests across 3-4 of them by default. The author switched to using Chromium only, making the suite 3-4 times faster to run.

The main downside to browser testing is the difficulty in achieving perfect test reliability, especially for SPAs. However, the author has mitigated this risk by setting Playwright's retries option to 2 in CI, which retries failed tests individually up to 2 times. The interactive Playwright UI is particularly helpful, as it creates a standalone HTML file with the same UI as the interactive Playwright runner whenever a test fails.

This trace file includes console logs, network request/response bodies, screenshots, and more, making troubleshooting easier.

The author also uses a test-only API route to test an important feature that cannot be broken. Tests are not isolated in environments, as they replicate how users would use the app in production. The author prefers to have high reliability in their test suite due to the large number of tests, and they aim to set retries to zero in CI, though they are not eager to tackle this task just yet.