Running UI Tests in Actions

Running browser-based UI tests like Playwright or Cypress on GitHub-hosted runners introduces extra considerations such as browsers, xvfb, and artifact handling. With a good setup, though, you can validate critical user flows on every pull request.

Configuring Playwright or Cypress in GitHub Actions #

Playwright offers a dedicated GitHub Action to install browsers, while Cypress provides its own actions and caching mechanisms. In both cases, you install dependencies, prepare browsers and run the test command in headless mode.

# Example: Playwright UI tests in Actions
name: Playwright Tests

on:
  pull_request:
    branches: [ main ]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - name: Install dependencies
        run: npm ci
      - name: Install Playwright browsers
        run: npx playwright install --with-deps
      - name: Run Playwright tests
        run: npx playwright test --reporter=line

Once basic runs are stable, add screenshots, videos and trace uploads as artifacts to help debug failures.

Common Mistakes #

Mistake 1 — Using local-only assumptions in CI #

This causes failures on runners.

❌ Wrong: Relying on locally running services or browsers that are not available in GitHub-hosted environments.

✅ Correct: Explicitly start required services (like your web app) and install browsers inside the workflow.

Mistake 2 — Running huge UI suites on every PR #

This slows feedback.

❌ Wrong: Running hours of UI tests on every small change.

✅ Correct: Define smoke vs regression suites and choose appropriate triggers for each.