---

name: testing-guide description: | Testing pyramid and test writing standards for UT/IT/ST/E2E. Supports ISTQB and Industry Pyramid frameworks. Use when: writing tests, discussing test coverage, test strategy, or test naming. Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 測試, 單元, 整合, 端對端.

Testing Guide

Language: English | 繁體中文

Version: 1.1.0 Last Updated: 2025-12-29 Applicability: Claude Code Skills

---

Purpose

This skill provides testing pyramid standards and best practices for systematic testing, supporting both ISTQB and Industry Pyramid frameworks.

Framework Selection

Note on Integration Testing abbreviation:

• IT (Integration Testing): Agile/DevOps communities
• SIT (System Integration Testing): Enterprise/ISTQB contexts
• Both refer to the same testing level

Quick Reference

Testing Pyramid (Industry Standard)

Copy              ┌─────────┐
              │   E2E   │  ← 10% (Fewer, slower)
             ─┴─────────┴─
            ┌─────────────┐
            │   IT/SIT    │  ← 20% (Integration)
           ─┴─────────────┴─
          ┌─────────────────┐
          │       UT        │  ← 70% (Unit)
          └─────────────────┘

Test Levels Overview

Coverage Targets

Detailed Guidelines

For complete standards, see:

• Testing Pyramid

AI-Optimized Format (Token-Efficient)

For AI assistants, use the YAML format files for reduced token usage:

• Base standard: ai/standards/testing.ai.yaml
• Framework options:
  • ISTQB Framework: ai/options/testing/istqb-framework.ai.yaml
  • Industry Pyramid: ai/options/testing/industry-pyramid.ai.yaml
• Test level options:
  • Unit Testing: ai/options/testing/unit-testing.ai.yaml
  • Integration Testing: ai/options/testing/integration-testing.ai.yaml
  • System Testing: ai/options/testing/system-testing.ai.yaml
  • E2E Testing: ai/options/testing/e2e-testing.ai.yaml

Naming Conventions

File Naming

Copy[ClassName]Tests.cs       # C#
[ClassName].test.ts       # TypeScript
[class_name]_test.py      # Python
[class_name]_test.go      # Go

Method Naming

Copy[MethodName]_[Scenario]_[ExpectedResult]()
should_[behavior]_when_[condition]()
test_[method]_[scenario]_[expected]()

Test Doubles

When to Use What

• UT: Use mocks/stubs for all external deps
• IT: Use fakes for DB, stubs for external APIs
• ST: Real components, fake only external services
• E2E: Real everything

AAA Pattern

Copytest('method_scenario_expected', () => {
    // Arrange - Setup test data
    const input = createTestInput();
    const sut = new SystemUnderTest();

    // Act - Execute behavior
    const result = sut.execute(input);

    // Assert - Verify result
    expect(result).toBe(expected);
});

FIRST Principles

• Fast - Tests run quickly
• Independent - Tests don't affect each other
• Repeatable - Same result every time
• Self-validating - Clear pass/fail
• Timely - Written with production code

Anti-Patterns to Avoid

• ❌ Test Interdependence (tests must run in order)
• ❌ Flaky Tests (sometimes pass, sometimes fail)
• ❌ Testing Implementation Details
• ❌ Over-Mocking
• ❌ Missing Assertions
• ❌ Magic Numbers/Strings

---

Testing Theory Essentials (YAML Compressed)

Copy# === ISTQB FUNDAMENTALS ===
terminology:
  error: "Human mistake in thinking"
  defect: "Bug in code (caused by error)"
  failure: "System behaves incorrectly (caused by defect)"
  chain: "Error → Defect → Failure"

oracle_problem:
  definition: "How do we know the expected result is correct?"
  approaches:
    - specification_oracle: "Compare against spec"
    - reference_oracle: "Compare against reference impl"
    - consistency_oracle: "Same input → same output"
    - heuristic_oracle: "Reasonable approximation"

# === STATIC vs DYNAMIC ===
static_testing:
  definition: "Examine without executing"
  techniques: [reviews, walkthroughs, inspections, static_analysis]
  finds: "Defects before runtime"
  examples: [ESLint, SonarQube, code_review]

dynamic_testing:
  definition: "Execute and observe behavior"
  techniques: [unit, integration, system, acceptance]
  finds: "Failures during execution"

# === TEST DESIGN TECHNIQUES ===
black_box:
  equivalence_partitioning:
    principle: "Divide inputs into equivalent classes"
    example: "Age: [<0 invalid], [0-17 minor], [18-64 adult], [65+ senior]"
  boundary_value:
    principle: "Test at boundaries of partitions"
    example: "Age: test -1, 0, 17, 18, 64, 65"
  decision_table:
    principle: "Combinations of conditions → actions"
    use: "Complex business rules"
  state_transition:
    principle: "Valid sequences of states"
    use: "Workflow, state machines"

white_box:
  statement_coverage: "Every statement executed once"
  branch_coverage: "Every decision branch taken"
  condition_coverage: "Every condition T/F"
  path_coverage: "Every possible path (often impractical)"

# === RISK-BASED TESTING ===
risk_assessment:
  likelihood: "How likely to fail?"
  impact: "How bad if fails?"
  priority: "likelihood × impact"

risk_matrix:
  high_high: "Test extensively, first priority"
  high_low: "Good coverage"
  low_high: "Good coverage"
  low_low: "Basic coverage"

# === DEFECT MANAGEMENT ===
defect_lifecycle:
  states: [new, assigned, in_progress, fixed, verified, closed]
  reopen_trigger: "Verification fails"

severity_vs_priority:
  severity: "Technical impact (critical/major/minor/trivial)"
  priority: "Business urgency (high/medium/low)"
  example: "Typo on login page: low severity, high priority (brand)"

# === TEST ENVIRONMENT ===
isolation_levels:
  unit: "In-memory, mocked deps"
  integration: "Containerized DB (Docker)"
  staging: "Production-like, isolated"
  production: "Real, feature flags for testing"

test_data_strategies:
  fixtures: "Static predefined data"
  factories: "Dynamic generation (faker)"
  snapshots: "Sanitized production copy"
  synthetic: "Algorithm-generated edge cases"

---

Configuration Detection

This skill supports project-specific configuration.

Detection Order

1. Check CONTRIBUTING.md for "Disabled Skills" section
   • If this skill is listed, it is disabled for this project
2. Check CONTRIBUTING.md for "Testing Standards" section
3. If not found, default to standard coverage targets

First-Time Setup

If no configuration found and context is unclear:

1. Ask the user: "This project hasn't configured testing standards. Would you like to customize coverage targets?"
2. After user selection, suggest documenting in CONTRIBUTING.md:

Copy## Testing Standards

### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |

Configuration Example

In project's CONTRIBUTING.md:

Copy## Testing Standards

### Coverage Targets
| Metric | Target |
|--------|--------|
| Line | 80% |
| Branch | 70% |
| Function | 85% |

### Testing Framework
- Unit Tests: Jest
- Integration Tests: Supertest
- E2E Tests: Playwright

---

Related Standards

• Testing Standards
• Code Review Checklist

---

Version History

---

License

This skill is released under CC BY 4.0.

Source: universal-dev-standards