Front-end Testing & Coverage

• Status: Active

• Last Modified: 2023-07-18

• Related Issue: 183

• Deciders: Sammy Steiner, Lucas Brown, Billy Daly, Andy Cochran

• Tags: ADR

Context and Problem Statement

Front-end testing is essential in maintaining a stable and healthy codebase, creating UI interfaces without regression, and an important part of the developer workflow.

Decision Drivers

• Robust: Chosen testing frameworks should have features that offer diverse ways of verifying front-end codebase functionality, reducing the need for intensive manual testing

• Well-maintained: Accessible tooling is well-maintained by owners and keeps up with current ecosystems in which it will be integrated.

• Ease of use: Achieving high coverage should be attainable. ICs should be able to onboard with the tooling and execute in a reasonable time frame to maintain that coverage.

• Fast: Running tests shouldn't take ages.

Options Considered

Unit Testing

• Jest

• Mocha

Pros and Cons of the Options

Jest

• Pros

  • Lightweight, well-supported and documented testing solution

  • Compatible with TypeScript, Node, React

  • Snapshot capabilities to track UI changes

  • Code coverage reporting that can be integrated into Github Actions

  • Already integrated in Next.js front-end template

  • Built-in mocking & auto-mocking

• Cons

  • Reports that snapshot capabilities are not for complicated UIs

  • Auto-mocking reduces performance

Mocha

• Pros

  • Has integration and end-to-end testing capabilities

  • More robust in functionality, offering a wider array of capabilities and helpers

  • Test coverage reporting available

  • Well-documented and widely used in Node.js ecosystems

• Cons

  • Not as lightweight as alternative, requiring integrating several other libraries

  • Does not support snapshot testing

  • Slower than Jest

Visual, Interactive & Component Testing

• Storybook

• Cypress

Pros and Cons of the Options

Storybook

• Pro

  • Build reusable UI components and pages in isolation, mocking external dependencies and business logic

  • Visually verify changes and debug on multiple device formats easily in the interface

  • Stories can be imported into Jest or other testing frameworks

  • Covers multiple testing types, including visual, interaction, component and accessibility

  • Compatible with many helpful addons to assist in building front-ends faster

  • Component testing addon uses Jest & Playwright under the hood for speed

  • Snapshot capabilities to address DOM regressions

  • Enhances collaboration between engineers and other team members such as designers

• Cons

  • May not be compatible with all tools and eco-systems

  • Initial ramp up for a conceptually new way of developing front-ends that ICs may not be accustomed with

  • Hasn't been around as long as other testing tools

Cypress

• Pro

  • Stubbing and mocking is simple comparatively

  • Well-documented with a long history of providing reliable end-to-end and component testing

  • Allows for visual debugging

  • Robust front-end end-to-end testing

  • Interactive GUI for end-to-end and component testing

• Cons

  • Functionality for our current use-case likely redundant with Storybook, need to maintain stories and component tests separately

  • Can be very slow to run the full test suite

  • Might easily get out of date as another tool and testing interface

  • Uses command queuing instead of familiar async await syntax like Storybook

  • Bundles many other third-party libraries

Decision Outcome

Unit Testing

Jest, because it is integrated into the Next.js template application, well-maintained, and lightweight. Importantly, documentation is thorough and helpful information for troubleshooting can be easily accessed.

Visual, Interactive & Component Testing

Storybook, because it provides an effective methodology for developing robust front-ends quickly. It is already implemented in the Next.js template application. Integration allows multiple ways to test applications, including compatibility with Jest.

In the future, if we find that Storybook doesn't meet our testing needs, we can look into integration with Cypress. However, not recommended from the start because our use-cases are covered by Storybook and there's a strong preference to not have to integrate another tool or learn another syntax.