CI/CD

GitHub Actions Testing: Complete CI/CD Integration Guide

HelpMeTest

HelpMeTest

— 5 min read
GitHub Actions Testing: Complete CI/CD Integration Guide

GitHub Actions has become the default CI/CD platform for most teams on GitHub — it's built in, free for public repos, and flexible enough for complex pipelines. But getting testing right in Actions requires more than copying a starter workflow. This guide covers the patterns that actually work in production.

A Minimal Test Workflow

Every GitHub Actions test pipeline starts with a workflow file in .github/workflows/:

name: Test

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

This runs on every push to main and on every pull request targeting main. Simple, but missing the optimizations that make CI fast and reliable.

Caching Dependencies

Dependency installation is often the slowest step. Cache it:

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

For Python:

- uses: actions/setup-python@v5
  with:
    python-version: '3.11'
    cache: 'pip'
- run: pip install -r requirements.txt

The built-in cache actions handle cache key generation automatically based on lock files. For custom caching (e.g., compiled binaries, Docker layers), use actions/cache directly:

- uses: actions/cache@v4
  with:
    path: ~/.gradle/caches
    key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
    restore-keys: |
      ${{ runner.os }}-gradle-

Matrix Builds: Test Across Versions

Run tests against multiple language versions or OS configurations simultaneously:

jobs:
  test:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
        node: [18, 20, 22]
      fail-fast: false

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm ci
      - run: npm test

fail-fast: false lets all matrix jobs complete even if one fails — useful for seeing which combinations break before fixing them.

Running Unit, Integration, and E2E Tests Separately

Splitting test types into separate jobs gives better visibility and faster feedback:

jobs:
  unit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run test:unit

  integration:
    runs-on: ubuntu-latest
    needs: unit
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpass
          POSTGRES_DB: testdb
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:testpass@localhost:5432/testdb

  e2e:
    runs-on: ubuntu-latest
    needs: [unit, integration]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx playwright install --with-deps chromium
      - run: npm run test:e2e

The needs field enforces ordering. E2E only runs if unit and integration pass.

Services: Databases and External Dependencies

GitHub Actions supports service containers — Docker images that run alongside your job:

services:
  redis:
    image: redis:7
    ports:
      - 6379:6379
    options: --health-cmd "redis-cli ping" --health-interval 10s --health-retries 5

  postgres:
    image: postgres:16
    env:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: apptest
    ports:
      - 5432:5432
    options: >-
      --health-cmd pg_isready
      --health-interval 10s
      --health-retries 5

Services start before your job steps and are reachable on localhost at the mapped port. Health options ensure the service is ready before your tests run.

Secrets Management

Store sensitive values in GitHub repository secrets (Settings > Secrets and variables > Actions):

- run: npm run test:e2e
  env:
    API_KEY: ${{ secrets.API_KEY }}
    DATABASE_URL: ${{ secrets.TEST_DATABASE_URL }}

Secrets are masked in logs automatically. Never hardcode credentials in workflow files or use echo to print secrets.

For environment-specific secrets, use GitHub Environments with protection rules that require manual approval before running against production secrets.

Test Reporting

Raw test output in logs is hard to read. Use artifact upload and the test reporter action:

- run: npm test -- --reporter=junit --output-file=test-results.xml
  continue-on-error: true

- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: test-results
    path: test-results.xml

- uses: dorny/test-reporter@v1
  if: always()
  with:
    name: Test Results
    path: test-results.xml
    reporter: java-junit

The if: always() condition ensures artifacts upload even when tests fail. continue-on-error: true on the test step prevents it from stopping artifact upload.

Coverage Reports

Enforce coverage thresholds and track trends:

- run: npm run test:coverage

- uses: actions/upload-artifact@v4
  with:
    name: coverage
    path: coverage/

- uses: codecov/codecov-action@v4
  with:
    token: ${{ secrets.CODECOV_TOKEN }}
    fail_ci_if_error: true
    threshold: 80

Or enforce locally without an external service:

- run: |
    npm run test:coverage
    COVERAGE=$(cat coverage/coverage-summary.json | jq '.total.lines.pct')
    if (( $(echo "$COVERAGE < 80" | bc -l) )); then
      echo "Coverage $COVERAGE% is below 80% threshold"
      exit 1
    fi

Parallelizing Long Test Suites

For large test suites, split tests across multiple jobs:

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        shard: [1, 2, 3, 4]
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npx playwright test --shard=${{ matrix.shard }}/4

Playwright, Vitest, and Jest all support test sharding. A 20-minute suite split across 4 jobs runs in ~5 minutes.

Workflow Optimization Patterns

Concurrency: Cancel in-progress runs when a new commit is pushed:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Path filtering: Only run tests when relevant files change:

on:
  push:
    paths:
      - 'src/**'
      - 'tests/**'
      - 'package.json'

Reusable workflows: Extract common test logic into a reusable workflow and call it from multiple repos:

# .github/workflows/reusable-tests.yml
on:
  workflow_call:
    inputs:
      node-version:
        required: true
        type: string

Debugging Failing CI Builds

When tests pass locally but fail in CI, the usual culprits are:

  1. Environment differences — use env to explicitly set variables instead of relying on shell config
  2. Timing issues — add health checks to services; use retry logic for flaky network calls
  3. Disk space — GitHub runners have ~14GB free; large test fixtures fill it
  4. Permissions — files created in one step may not be executable in another; use chmod explicitly

Enable debug logging temporarily with ACTIONS_RUNNER_DEBUG: true in your workflow env or by re-running with debug mode enabled in the GitHub UI.

Testing Your Actual Application

Running tests in GitHub Actions tells you if your code works in isolation. To verify that your entire deployed application works — across browsers, with real user flows — HelpMeTest runs automated tests against your live app from anywhere in the world. No CI configuration required, no Playwright setup to maintain. Define tests in plain English, and HelpMeTest runs them on a schedule or on each deploy.

Summary

A production-ready GitHub Actions test pipeline includes:

  • Dependency caching to keep installs fast
  • Matrix builds for cross-version compatibility
  • Separate jobs for unit, integration, and E2E with needs ordering
  • Service containers for databases and external dependencies
  • Proper secrets management
  • Test reporting via artifacts and third-party reporters
  • Concurrency controls to cancel stale runs
  • Coverage enforcement to prevent regressions

The bottleneck in most pipelines isn't the framework — it's test suite design. Keep unit tests fast (under 1s each), keep integration tests isolated, and reserve E2E for the flows that matter most.

Read more