Part 5.6 — Running Frontend Tests in CI & Keeping Them Maintainable

A test that only runs on a developer’s machine is a suggestion.
A test that runs in CI is a rule.

This final post of Part 5 focuses on operational reality: wiring your React test suite into CI, preventing flaky failures, and keeping tests maintainable as the codebase grows.

This is where frontend testing becomes a team habit instead of an afterthought.

1. The CI Goal for Frontend Tests

Your CI pipeline should guarantee that:

• the app builds

• component tests pass

• E2E tests pass

• failures are actionable

• results are reproducible locally

Speed matters—but determinism matters more.

2. Split Test Responsibilities Clearly

Frontend testing in CI should be split:

• Jest tests → fast feedback on components and logic

• Playwright tests → confidence in real user flows

Never mix these concerns.

3. Add CI Scripts to package.json

You already added:

"scripts": {
  "test": "jest",
  "test:watch": "jest --watch",
  "test:ci": "jest --runInBand",
  "e2e": "playwright test"
}

These scripts become the contract CI relies on.

4. GitHub Actions: Frontend CI Workflow

A minimal but production-grade workflow:

name: Frontend Tests

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: pnpm/action-setup@v4
        with:
          version: 8

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'pnpm'

      - run: pnpm install

      - run: pnpm test:ci

      - run: pnpm exec playwright install --with-deps

      - run: pnpm e2e

This runs:

• Jest tests first (fast failure)

• Playwright tests after

Failures stop the pipeline immediately.

5. Start Backend Dependencies in CI (When Needed)

If Playwright tests hit a real backend:

• start NestJS API

• start PostgreSQL test DB

This usually happens in Part 11 & 12, but conceptually:

• backend tests validate API correctness

• frontend E2E tests validate integration

Never run E2E tests against production.

6. Use Environment Variables Explicitly

In CI, be explicit:

env:
  VITE_API_URL: http://localhost:3000

Avoid relying on defaults.

Missing env vars are the #1 cause of CI-only failures.

7. Make Playwright Failures Actionable

Playwright automatically captures:

• screenshots

• videos

• traces

Ensure CI uploads them:

- uses: actions/upload-artifact@v4
  if: failure()
  with:
    name: playwright-report
    path: playwright-report

This turns “it failed” into “I see exactly why”.

8. Prevent Flaky Frontend Tests

Most frontend flakiness comes from:

• async UI not awaited

• race conditions

• network assumptions

• time-based assertions

Rules to enforce:

• always use findBy / waitFor

• never use setTimeout

• never assert on animation timing

• avoid nth-child selectors

• avoid randomness without seeding

If a test flakes once, fix it immediately.

9. Keep E2E Tests Few and Valuable

E2E tests are expensive.

If your Playwright suite grows beyond ~20 tests, ask:

• is this better covered by component tests?

• is this duplicating coverage?

• is this testing UI polish instead of behavior?

E2E tests should protect flows, not pixels.

10. Use Test Tags for Control (Advanced)

Playwright supports tagging:

test('@smoke homepage loads', async () => { ... });

Run subsets:

pnpm e2e --grep @smoke

This allows:

• fast smoke checks

• full suite nightly

• targeted debugging

Use this sparingly but intentionally.

11. Refactor Tests Like Production Code

Test code is not disposable.

Refactor when you see:

• repeated selectors

• duplicated setup

• brittle assertions

• confusing failures

Clean tests reduce cognitive load across the team.

12. Enforce Testing Discipline with CI

CI should:

• block merges on failure

• run on every PR

• be visible to the team

• fail fast and loudly

Tests that don’t block merges slowly stop being written.

13. How to Know Your Frontend Tests Are Healthy

Healthy test suites have:

• stable CI runtime

• rare flakes

• readable failures

• confidence during refactors

• no fear of deployment

Unhealthy test suites create avoidance and workarounds.

14. Summary

You now know how to:

• run React component tests in CI

• run Playwright E2E tests in CI

• configure pnpm-based workflows

• surface actionable failure artifacts

• prevent flaky frontend tests

• keep test suites maintainable long-term

This completes Part 5 — Testing React Apps.