Testing Strategy Skill

Purpose

Comprehensive testing guidelines including test pyramid, coverage targets, and test patterns.

Auto-Invoke Triggers

• •Planning test strategy
• •Writing unit/integration tests
• •Reviewing test coverage
• •Setting up test infrastructure

Test Pyramid

        /\
       /  \      E2E Tests (10%)
      /----\     - Critical user flows
     /      \    - Slow, expensive
    /--------\   Integration Tests (20%)
   /          \  - API tests, DB tests
  /------------\ - Medium speed
 /              \ Unit Tests (70%)
/----------------\ - Fast, isolated
                   - Business logic

Distribution Guidelines

Coverage Targets

What to Cover

• •All public methods
• •Business logic
• •Edge cases
• •Error handling
• •Integration points

What NOT to Cover

• •Generated code
• •Simple getters/setters
• •Framework code
• •Third-party libraries

Unit Testing

Principles

• •Test one thing per test
• •Tests should be fast (< 100ms)
• •Tests should be isolated
• •Tests should be deterministic
• •No external dependencies

AAA Pattern

Arrange - Set up test data and mocks
Act     - Execute the method under test
Assert  - Verify the expected outcome

Naming Convention

{Method}_{Scenario}_{ExpectedResult}

CreateUser_ValidData_ReturnsUserId
CreateUser_DuplicateEmail_ThrowsConflict
CalculateTotal_EmptyCart_ReturnsZero

Test Categories

Integration Testing

Scope

• •API endpoints
• •Database operations
• •External service calls
• •Message queues

Best Practices

• •Use test containers or in-memory DB
• •Seed known test data
• •Clean up after each test
• •Mock external services
• •Test full request/response cycle

API Test Checklist

• • Correct status code
• • Response body structure
• • Headers (content-type, auth)
• • Validation errors
• • Authorization rules

E2E Testing

When to Use

• •Critical user journeys
• •Payment flows
• •Authentication flows
• •Multi-step workflows

Best Practices

• •Test user perspective, not implementation
• •Use stable selectors (data-testid)
• •Handle async operations properly
• •Keep tests independent
• •Use page object pattern

Critical Paths to Test

• •User registration/login
• •Main feature workflow
• •Payment/checkout
• •Error recovery flows

Test Data Management

Strategies

Rules

• •Use realistic but fake data
• •Never use production data
• •Reset state between tests
• •Use faker libraries for variety

Mocking Guidelines

When to Mock

• •External services (APIs, databases)
• •Time-dependent operations
• •Random values
• •Expensive operations

When NOT to Mock

• •Simple value objects
• •The code under test
• •Everything (over-mocking)

Mock Types

Test Organization

File Structure

tests/
├── unit/
│   ├── services/
│   └── utils/
├── integration/
│   ├── api/
│   └── db/
├── e2e/
├── fixtures/
└── conftest.py / setup.ts

Naming

• •Test files: {module}_test.py or {module}.test.ts
• •Match source structure
• •Group related tests in describe/class

CI/CD Integration

Pipeline Stages

1. •Unit tests - Run on every commit
2. •Integration tests - Run on PR/merge
3. •E2E tests - Run on deploy to staging

Quality Gates

Performance Testing

Types

Metrics to Measure

• •Response time (p50, p95, p99)
• •Throughput (requests/second)
• •Error rate
• •Resource usage

Best Practices

DO

• •Write tests before fixing bugs
• •Test behavior, not implementation
• •Keep tests simple and readable
• •Run tests frequently
• •Maintain test code quality
• •Use meaningful assertions

DON'T

• •Test private methods directly
• •Write flaky tests
• •Skip tests temporarily (delete instead)
• •Test external systems
• •Ignore slow tests
• •Copy-paste test code

Test Quality Checklist

• • Tests are fast (< 10s for unit suite)
• • Tests are isolated (no order dependency)
• • Tests are deterministic (no flakiness)
• • Tests are readable (clear intent)
• • Tests cover edge cases
• • Tests verify error handling
• • Mocks are minimal and purposeful
• • CI runs tests automatically