E2e Testing Strategies | The Garnet Wiki

End-to-end testing strategies define how an engineering team validates the complete flow of a system—from user interaction to backend processing and external integrations—under real-world conditions. This is not about testing a single API or a UI component in isolation. It matters when a new feature must work across multiple services, when user data must persist through a complex transaction, and when a failure in one service cascades through the entire system. Use this page when you need to decide how to run, maintain, and scale your E2E test suite across development, staging, and production.

Choosing Test Scope and Coverage

The foundation of an effective E2E strategy is a clear definition of what "end-to-end" means for your system. It begins with identifying the primary user journeys that must be tested. These journeys are not just functional steps but include timing, data state, and external dependencies.

A test suite should cover at least:

Core user flows: e.g., “User signs up, verifies email, creates first project, uploads file.”
Critical integrations: e.g., “Payment completes via Stripe, triggers email via SendGrid, updates CRM.”
Failure scenarios: e.g., “User submits form while offline, then reconnects; data syncs on resume.”

Coverage is determined by specifying test boundaries in code or configuration. For example:


test-suites:
  - name: user-onboarding
    description: "Sign-up, verification, project creation, file upload"
    coverage:
      - user-journey: signup
      - external-service: sendgrid
      - database: postgres
      - queue: rabbitmq
    test-entries:
      - path: /signup
        steps:
          - click: "button#submit"
          - wait-for: "div#confirmation"
          - expect: "text", "Welcome, {user.name}"
        dependencies:
          - service: email-service
          - database: auth-db
          - queue: email-queue

Each test entry must declare what it assumes to be true before execution and what it expects to be true after. A common failure is assuming a service is up but not verifying it. Use curl to probe health endpoints before running a test:

# Before starting a test suite
curl -f http://auth-service:8080/health
if [ $? -ne 0 ]; then
  echo "Auth service not ready" >&2
  exit 1
fi

A test may fail silently if the database is not seeded with initial data. Use psql to verify data:

psql -c "SELECT count(*) FROM users WHERE email = '[email protected]'" -d myapp
# Expected: 1

The most common oversight is not validating time. A test may pass but miss a timing dependency: e.g., an email is sent, but the confirmation link expires before the test expects it. Use sleep and timeout to control test timing:

# Wait up to 30 seconds for email to arrive
timeout 30s bash -c '
  while ! curl -s http://mail-service:8080/inbox/[email protected] | grep "Welcome"; do
    sleep 2
  done
'

Running Tests in Different Environments

The strategy for running E2E tests varies significantly between development, CI, and production. Each environment has distinct constraints and priorities.

In development, engineers run E2E tests locally with a full stack. Use docker-compose to spin up services:

# docker-compose.yml
services:
  app:
    build: .
    ports:
      - "3000:3000"
    depends_on:
      - db
      - redis
      - email-service
  db:
    image: postgres:15
    environment:
      POSTGRES_DB: testdb
      POSTGRES_USER: testuser
      POSTGRES_PASSWORD: testpass
  email-service:
    image: sendgrid/email-service:latest
    ports:
      - "8080:8080"
    command: ["--config", "/config.yaml"]

Run tests with npm run e2e or make e2e, which starts the stack and executes tests via a test runner like jest or cucumber.

In CI, tests must be fast, reliable, and parallelizable. Use gitlab-ci.yml or github-actions.yml to orchestrate test execution:

# .gitlab-ci.yml
e2e-tests:
  image: node:18
  services:
    - docker:dind
  before_script:
    - docker-compose up -d --wait
    - npm install
  script:
    - npm run e2e -- --reporter=spec --timeout=60000
  artifacts:
    paths:
      - reports/
    expire_in: 1 week
  only:
    - main

A common failure is flaky tests due to services starting asynchronously. Use docker-compose exec to check readiness:

docker-compose exec app sh -c '
  until curl -f http://localhost:3000/health; do
    echo "App not ready, waiting..."
    sleep 2
  done
'

In production, E2E tests serve as a canary. Run them on a per-deployment basis using a cron or event-driven trigger. Use kubectl to deploy a test runner pod:

kubectl apply -f - <<'EOF'
apiVersion: batch/v1
kind: Job
metadata:
  name: e2e-canary
spec:
  template:
    spec:
      containers:
        - name: test-runner
          image: myorg/e2e-runner:v1.2
          command: ["/app/test.sh"]
          env:
            - name: DATABASE_URL
              value: "postgresql://prod-db:5432/myapp"
            - name: BASE_URL
              value: "https://app.mycompany.com"
      restartPolicy: OnFailure
  backoffLimit: 4
EOF

The job runs a script that collects metrics and logs failures. A production E2E test should not only pass/fail but also record latency, error rates, and screenshots.

Managing Flakiness and Reliability

Flaky E2E tests are the silent killers of confidence. They pass in CI but fail in production, and vice versa. The root causes are timing, state, and external service instability.

A key technique is test retry with exponential backoff. Use jest with retry configuration:

// jest.config.json
{
  "testTimeout": 60000,
  "maxWorkers": 4,
  "testRetryTimes": 2,
  "testRetryDelay": 1000
}

Each test runs up to three times, with 1 second between attempts. If a test fails, it logs the full browser state: screenshots, console logs, and network traces.

Another approach is test isolation via test data management. Every test should create and clean up its own data. Use psql scripts to seed and reset state:

# setup-test-data.sh
psql -d testdb -c "
  INSERT INTO users (id, email, name) VALUES (1, '[email protected]', 'Test User');
  INSERT INTO projects (user_id, title) VALUES (1, 'Test Project');
"

# teardown-test-data.sh
psql -d testdb -c "
  DELETE FROM projects WHERE user_id = 1;
  DELETE FROM users WHERE email = '[email protected]';
"

Run these scripts before and after each test suite.

Flakiness often stems from external service dependencies. A test may fail because the email service is down, but the failure is not visible. Use curl to probe and validate responses:

# Check if email was sent
curl -s http://mail-service:8080/api/v1/[email protected] | jq -e '.[0].subject == "Welcome to MyApp"'
if [ $? -ne 0 ]; then
  echo "Email subject mismatch" >&2
  exit 1
fi

A subtle but critical pattern is test metadata and reporting. Each test should include:

Start time
Environment (CI/Prod)
Test parameters (e.g., browser, viewport size)
A unique ID

This metadata enables correlation of test results with CI logs, service metrics, and user actions.

Scaling the Test Suite

As the number of tests grows, so does the cost of execution. A strategy must address how to scale the suite without sacrificing speed or reliability.

Use parallelization across test files. Split the test suite into chunks and run them in parallel using --parallel or --jobs:

# Run 4 test files in parallel
jest --parallel --jobs=4 --coverage

For larger systems, use sharding based on test file names or tags:

# Assign test files to 3 shards
jest --shard=1/3 --runInBand
jest --shard=2/3 --runInBand
jest --shard=3/3 --runInBand

Each shard runs its own test suite, sharing the same services but independent of others.

To reduce execution time, cache test data and artifacts. Use docker volume mounts or s3 to store pre-seeded databases and test assets:

services:
  db:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data
      - db-backup:/backups
    command: ["--data-checksums"]

Before running tests, restore from a known backup:

docker exec -i db pg_restore -d myapp /backups/latest.dump

Another strategy is test prioritization. Run high-priority tests (e.g., checkout flow) on every CI commit, and run the full suite only on nightly or release builds.

Use test tagging to control this:

// e2e-tests/checkout.spec.js
describe('Checkout flow', () => {
  it('should complete purchase with credit card', async () => {
    // test steps
  }, { tags: ['checkout', 'slow', 'critical'] });

Then, in CI, run only tests tagged critical:

jest --tag=critical --reporter=summary

Handling Failures and Diagnosing Breakages

When an E2E test fails, the immediate need is to understand why. The failure must be diagnostic, not just pass/fail.

A robust strategy includes automatic artifact capture. On failure, the test runner captures:

Screenshots of the browser at each step
Console logs
Network requests and responses
Full database dumps

Use jest with testEnvironment: 'jest-environment-puppeteer' and afterAll hooks:

// setupTests.js
beforeAll(async () => {
  await page.setViewport({ width: 1280, height: 720 });
});

afterAll(async () => {
  await page.screenshot({ path: 'screenshots/failure.png' });
  await page.pdf({ path: 'reports/failure.pdf' });
  await page.evaluate(() => {
    const logs = console.log;
    return { logs };
  });
});

Failure output should include:

Test name and tags
Environment and service versions
Timestamps for each step
A summary of the test execution flow

A common failure mode is test data drift. A test that passes today fails tomorrow because a user was created in the wrong state. Use psql and curl to validate test data after a failure:

# After test failure
psql -d myapp -c "SELECT * FROM users WHERE email = '[email protected]'"
curl http://api.myapp.com/users/[email protected]

A final diagnostic technique is test replay. When a test fails, record a full session (e.g., via puppeteer or playwright) and store it as a video or trace. Use playwright to generate trace files:

npx playwright test --trace on

These traces can be opened in playwright trace viewer and used to debug failures in production.

Maintaining the Test Suite

An E2E suite is not static. It must evolve with the system. Use test versioning to track changes in test logic and data.

Version test metadata in package.json:

{
  "e2e": {
    "version": "1.4",
    "last-run": "2025-03-15T10:00:00Z",
    "tags": ["user-onboarding", "checkout"]
  }
}

Use git to track test changes:

git add e2e-tests/
git commit -m "Add test for mobile signup flow"
git push origin main

When a test fails, create a failure report with:

A summary of the failure
Links to CI logs
Screenshots and traces
A checklist for triaging the issue

Use systemctl to run a test maintenance job:

# /etc/systemd/system/e2e-maintenance.service
[Unit]
Description=E2E Test Maintenance
After=network.target

[Service]
Type=oneshot
ExecStart=/opt/scripts/run-e2e-report.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

This job runs nightly and sends a report to the engineering team, flagging failing tests and changes in execution time.

An E2E testing strategy is not a checklist. It is a living system of decisions, trade-offs, and patterns—each validated by the cost of a failing test in production.

This page was rewritten on 18 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.