Expert Test Automator

A senior test automation engineer that designs and implements comprehensive test automation strategies, covering framework development, test script creation, CI/CD integration, and test maintenance for high coverage and fast feedback loops.

When to Use This Agent

Choose Expert Test Automator when:

• Setting up test automation frameworks from scratch
• Automating manual test suites for regression testing
• Integrating automated tests into CI/CD pipelines
• Building custom test utilities, fixtures, and data generators
• Migrating between test automation frameworks

Consider alternatives when:

• Writing individual test cases for specific functions (use Test Generator Pro)
• Designing QA strategy and test plans (use Expert QA Bot)
• Running performance or load tests (use a performance engineering agent)

Quick Start

Copy
# .claude/agents/expert-test-automator.yml
name: Expert Test Automator
description: Design and implement test automation frameworks
model: claude-sonnet
tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep

Example invocation:

claude "Set up a complete test automation framework for our Next.js app with Vitest for unit tests, Playwright for E2E, and GitHub Actions integration"

Core Concepts

Test Automation Architecture

Layer	Framework	Scope	Run Frequency
Unit	Vitest/Jest	Functions, hooks, utilities	Every commit
Component	Testing Library	React components	Every commit
Integration	Supertest + Vitest	API endpoints, services	Every PR
E2E	Playwright	User workflows	Pre-merge, nightly
Visual	Playwright screenshots	UI regression	Pre-release

Framework Setup Pattern

Copy
// vitest.config.ts — Unit + Integration
import { defineConfig } from 'vitest/config';
import react from '@vitejs/plugin-react';
import tsconfigPaths from 'vite-tsconfig-paths';

export default defineConfig({
  plugins: [react(), tsconfigPaths()],
  test: {
    globals: true,
    environment: 'jsdom',
    setupFiles: ['./test/setup.ts'],
    include: ['src/**/*.test.{ts,tsx}'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
      exclude: ['node_modules/', 'test/', '**/*.d.ts'],
      thresholds: {
        branches: 80,
        functions: 80,
        lines: 80,
        statements: 80,
      },
    },
  },
});

// test/setup.ts — Global test setup
import '@testing-library/jest-dom/vitest';
import { cleanup } from '@testing-library/react';
import { afterEach, vi } from 'vitest';

afterEach(() => {
  cleanup();
  vi.restoreAllMocks();
});

// Mock global browser APIs
Object.defineProperty(window, 'matchMedia', {
  value: vi.fn().mockImplementation((query) => ({
    matches: false,
    media: query,
    addEventListener: vi.fn(),
    removeEventListener: vi.fn(),
  })),
});

CI/CD Pipeline Integration

Copy
# .github/workflows/test.yml
name: Test Suite
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  unit-tests:
    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 -- --coverage
      - uses: codecov/codecov-action@v4

  e2e-tests:
    runs-on: ubuntu-latest
    needs: unit-tests
    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
      - uses: actions/upload-artifact@v4
        if: failure()
        with:
          name: playwright-traces
          path: test-results/

Configuration

Parameter	Description	Default
unit_framework	Unit test framework (vitest, jest, mocha)	Auto-detect
e2e_framework	E2E test framework (playwright, cypress)	playwright
coverage_target	Minimum code coverage percentage	80
ci_provider	CI/CD platform (github-actions, gitlab-ci)	github-actions
parallel_workers	Test parallelization level	auto
reporting	Test report format (html, json, junit)	["html", "json"]

Best Practices

1. Structure the automation framework in layers with clear boundaries. Separate test utilities (data factories, API clients, page objects) from test cases. Utilities change infrequently and are shared across many tests. Test cases change frequently as features evolve. This separation prevents utility changes from breaking unrelated tests and makes both layers independently maintainable.

2. Create a test data factory layer instead of hardcoding data in tests. Factory functions that generate valid test entities with sensible defaults and easy overrides make tests readable and maintainable. When a data schema changes, update the factory once instead of 50 individual tests. Use libraries like Faker for realistic generated data that also catches edge cases (long names, special characters).

3. Run the fastest tests first in CI to fail fast. Order CI jobs so linting and type checking run first (seconds), then unit tests (minutes), then integration tests (minutes), then E2E tests (tens of minutes). If linting fails, there is no reason to wait 20 minutes for E2E results. Use CI job dependencies to skip expensive steps when cheap steps fail.

4. Monitor and fix flaky tests immediately — do not disable them. A flaky test is a test with a bug, either in the test itself or in the application. Disabling it removes a regression detection mechanism. When a test becomes flaky, investigate the root cause: timing issues, shared state, external dependencies, or race conditions. Fix the root cause rather than adding retries or increasing timeouts, which mask the underlying problem.

5. Generate test reports that are actionable, not just informative. Test reports should answer three questions: What failed? Why did it fail? How do I reproduce it? Include failure screenshots, trace files, and error messages in CI artifacts. Link test failures to specific code changes using git blame. A developer should be able to start debugging within 30 seconds of seeing a test failure notification.

Common Issues

Test suite execution time grows uncontrollably as the project scales. Without intervention, test suites grow from 2 minutes to 20 minutes, blocking CI and discouraging local test runs. Implement test sharding across parallel CI workers. Use Vitest's --changed flag to run only tests affected by modified files. Profile the slowest tests and optimize them — often a few slow tests account for most of the total runtime.

Tests pass locally but fail in CI due to environment differences. Different Node.js versions, OS-specific behavior, timezone differences, and missing system dependencies cause environment-specific failures. Pin Node.js version in CI and locally (via .nvmrc). Use TZ=UTC for timezone-sensitive tests. Containerize the test environment with Docker to guarantee consistency. Run CI tests locally with act before pushing.

Mocking strategy becomes inconsistent across the test suite. Some tests mock at the module level, others at the function level, some use manual mocks and others use vi.mock(). Establish a mocking strategy document: mock external I/O (HTTP, database, file system) at the module boundary, use dependency injection for service-level mocking, and never mock the code under test. Enforce the strategy through code review and shared test utilities.