testing-strategy（测试策略）

Testing Strategy

Overview

Analyze the project context and recommend a comprehensive testing strategy. This skill selects appropriate frameworks, defines the testing pyramid, establishes coverage thresholds, and generates test configuration files. The goal is a repeatable, measurable testing foundation that the team can maintain.

Announce at start: "I'm using the testing-strategy skill to define the testing approach."

Phase 1: Analyze Project

Goal: Understand the current stack, existing tests, and CI setup before recommending anything.

Actions

1. Identify the tech stack (language, framework, runtime)
2. Survey existing tests (what testing exists already?)
3. Review CI/CD pipeline (how do tests run?)
4. Measure current coverage levels
5. Map external dependencies (services, databases, APIs)

Discovery Commands

# Identify test files
find . -name "*.test.*" -o -name "*.spec.*" | head -30

# Check for test config
ls vitest.config.* jest.config.* pytest.ini pyproject.toml .mocharc.* 2>/dev/null

# Check current coverage
cat coverage/coverage-summary.json 2>/dev/null || echo "No coverage report found"

# Check CI config
cat .github/workflows/*.yml 2>/dev/null | head -50

STOP — Do NOT proceed to Phase 2 until:

• Tech stack is identified
• Existing test infrastructure is mapped
• CI pipeline status is known
• External dependencies are listed

Phase 2: Recommend Testing Pyramid

Goal: Select frameworks and define the pyramid ratios.

Framework Selection Table

Testing Pyramid Ratios

        /\
       /  \     E2E Tests (10%)
      /    \    Critical user journeys only
     /------\
    /        \   Integration Tests (30%)
   /          \  API endpoints, DB queries, service interactions
  /------------\
 /              \ Unit Tests (60%)
/                \ Pure functions, business logic, utilities

What to Test at Each Level

STOP — Do NOT proceed to Phase 3 until:

• Framework selection matches the tech stack
• Pyramid ratios are defined
• Testing scope at each level is documented

Phase 3: Define Coverage Thresholds

Goal: Set realistic, enforceable coverage targets.

Coverage Threshold Table

Threshold Selection Decision Table

STOP — Do NOT proceed to Phase 4 until:

• Coverage thresholds are realistic for the project maturity
• Critical path coverage targets are defined
• CI enforcement strategy is decided

Phase 4: Generate Configuration

Goal: Produce working test configuration files and CI integration.

Actions

1. Generate test runner config (vitest.config.ts, jest.config.js, pytest.ini)
2. Configure coverage with thresholds
3. Add test commands to CI workflow
4. Set up test environment (.env.test, test databases)

Example: Vitest Config

import { defineConfig } from 'vitest/config';

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

STOP — Do NOT proceed to Phase 5 until:

• Config files are syntactically valid
• Coverage thresholds match Phase 3 decisions
• CI integration commands are defined

Phase 5: Create Test Templates

Goal: Provide example test files demonstrating project conventions.

Actions

1. Create a unit test example with Arrange-Act-Assert
2. Create an integration test with setup/teardown
3. Create mock/stub patterns for external dependencies
4. Create test data factories/fixtures
5. Create a snapshot test example (when appropriate)

STOP — Verification Gate before claiming complete:

• Framework selection matches tech stack
• Coverage thresholds are realistic
• Test configuration files are valid
• Example tests actually run
• CI integration is configured

Anti-Patterns / Common Mistakes

Decision Table: Mock Strategy

Integration Points

Key Principles

• Test behavior, not implementation — what it does, not how
• Fast feedback — unit tests should run in seconds
• Deterministic — no flaky tests, no time-dependent logic
• Readable — tests are documentation; make them clear
• Maintainable — tests should help refactoring, not block it

Skill Type

FLEXIBLE — Adapt framework selection and coverage thresholds to the project context. The five-phase process and testing pyramid structure are strongly recommended but can be scaled to project size.