Testing Strategy Composer

Purpose & When-To-Use

Trigger conditions:

• Starting a new project that needs a comprehensive testing approach
• Existing codebase with insufficient or imbalanced test coverage
• Technical debt remediation requiring systematic test improvement
• Architecture changes necessitating test strategy reassessment
• Team onboarding requiring clear testing guidelines

Use this skill when you need to establish or improve testing practices with clear ROI, balanced coverage across the test pyramid, and framework-specific implementation guidance.

Pre-Checks

Before execution, verify:

1. Time normalization: NOW_ET = 2025-10-25T21:30:36-04:00 (NIST/time.gov semantics, America/New_York)
2. Input schema validation:
   • system_description is non-empty string or parseable diagram
   • tech_stack contains at least one technology identifier
   • constraints (if provided) includes valid keys: budget, time, team_size
   • existing_coverage (if provided) has numeric metrics
3. Source freshness: All cited sources accessed on NOW_ET; verify links resolve
4. Framework compatibility: Confirm tech_stack technologies have known testing frameworks

Abort conditions:

• System description is too vague to identify testable components
• Tech stack includes only proprietary/undocumented technologies
• Constraints are contradictory (e.g., "zero budget" + "100% coverage")

Procedure

T1: Fast Path (≤2k tokens)

Goal: Analyze system and recommend test type distribution.

1. Parse system description:

   • Identify architecture pattern (monolith, microservices, serverless, mobile, etc.)
   • Extract key components (API, database, UI, services, jobs)
   • Determine complexity level (simple/moderate/complex)

2. Apply test pyramid heuristics (based on Martin Fowler's Test Pyramid, accessed 2025-10-25):

   • Unit tests (70%): Business logic, utilities, pure functions
   • Integration tests (20%): Database, API contracts, external services
   • E2E tests (10%): Critical user journeys, smoke tests
   • Adjust ratios based on architecture (e.g., API-only systems: 60/30/10)

3. Output initial recommendation:

   {
     "test_distribution": {
       "unit": 70,
       "integration": 20,
       "e2e": 10
     },
     "priority_areas": ["auth", "payment", "data-sync"],
     "estimated_effort_hours": 40
   }
   

Token budget: ≤2k tokens

T2: Extended Analysis (≤6k tokens)

Goal: Generate test scaffolding, calculate gaps, and create execution plan.

4. Map tech stack to testing frameworks:

   • JavaScript/Node.js → Jest, Mocha, Supertest, Playwright
   • Python → pytest, unittest, Selenium
   • Java → JUnit, Mockito, RestAssured
   • C# → xUnit, NUnit, SpecFlow
   • Consult [Microsoft Testing Patterns](https://learn.microsoft.com/en-us/dotnet/core/testing/, accessed 2025-10-25)

5. Generate framework-specific scaffolding:

   • Unit test template with arrange-act-assert pattern
   • Integration test template with setup/teardown
   • E2E test template for critical path
   • Performance test baseline (if applicable)
   • Reference [Google Testing Blog](https://testing.googleblog.com/, accessed 2025-10-25) for best practices

6. Identify coverage gaps:

   • Compare existing_coverage to targets
   • Calculate gap percentage per test type
   • Prioritize by risk (auth > payments > admin)
   • Output JSON with specific untested modules

7. Create phased execution plan:

   • Phase 1 (Week 1): High-risk unit tests
   • Phase 2 (Week 2): Integration tests for data layer
   • Phase 3 (Week 3): E2E critical paths
   • Phase 4 (Week 4): Performance baselines + refactor
   • Apply ISTQB Foundation principles ([ISTQB](https://www.istqb.org/certifications/certified-tester-foundation-level, accessed 2025-10-25))

Token budget: ≤6k tokens total (including T1)

T3: Deep Dive (not implemented for this skill)

T3 is not required for this P0 skill; T2 provides sufficient depth for most testing strategies.

Decision Rules

Test distribution adjustments:

• Microservices: Increase integration to 30%, decrease unit to 60%
• Mobile apps: Increase E2E to 20% (UI-critical), decrease integration to 15%
• API-only: Integration to 35%, unit to 55%, E2E to 10%
• ML/Data pipelines: Add performance tests (10%), adjust others proportionally

Effort estimation (per 1000 LOC):

• Unit tests: 4-8 hours
• Integration tests: 8-16 hours
• E2E tests: 16-24 hours
• Performance tests: 20-40 hours

Coverage thresholds (from [Martin Fowler Testing](https://martinfowler.com/testing/, accessed 2025-10-25)):

• Minimum acceptable: 60%
• Target for production: 80%
• Aspirational: 90%+ (diminishing returns above 85%)

Stop conditions:

• If constraints allow <10 hours: recommend T1 fast path only (unit tests for critical paths)
• If no testable components identified: emit TODO and request clarification
• If tech_stack is purely manual/visual testing: redirect to exploratory testing skill

Output Contract

Required fields (all outputs):

interface TestStrategy {
  strategy: string;              // Markdown document (200-800 words)
  test_distribution: {
    unit: number;                // Percentage (0-100)
    integration: number;
    e2e: number;
    performance?: number;
  };
  priority_areas: string[];      // Top 3-5 high-risk components
  estimated_effort_hours: number;
}

interface TestScaffolding {
  framework: string;             // e.g., "Jest", "pytest"
  unit_template: string;         // Code snippet
  integration_template: string;
  e2e_template: string;
  setup_instructions: string;    // Installation/config steps
}

interface CoverageGaps {
  current_coverage_percent: number;
  target_coverage_percent: number;
  gap_percent: number;
  untested_modules: Array<{
    name: string;
    risk: "high" | "medium" | "low";
    estimated_effort_hours: number;
  }>;
}

interface ExecutionPlan {
  phases: Array<{
    phase_number: number;
    duration_weeks: number;
    focus_area: string;
    deliverables: string[];
    success_criteria: string;
  }>;
  total_duration_weeks: number;
  dependencies: string[];        // External blockers
}

Format:

• test_strategy: Markdown with headings (## Overview, ## Test Types, ## Rationale)
• test_scaffolding: Code blocks with language hints (```javascript)
• coverage_gaps: Valid JSON
• execution_plan: Markdown with tables or numbered lists

Validation:

• All percentages sum to 100 (±2% rounding tolerance)
• Effort estimates are positive integers
• Phase dependencies are acyclic

Examples

Example 1: REST API System (T2)

INPUT:
  system_description: "REST API with Node.js/Express, PostgreSQL, Redis"
  tech_stack: ["node.js", "express", "jest", "supertest"]
  existing_coverage: {unit: 45, integration: 10, e2e: 0}

OUTPUT:
  test_distribution: {unit: 65, integration: 25, e2e: 10}

  scaffolding:
    # Unit test (Jest)
    describe('UserService', () => {
      it('hashes password', () => {
        expect(hashPassword('secret')).not.toBe('secret');
      });
    });

    # Integration test
    describe('POST /users', () => {
      it('creates user in DB', async () => {
        const res = await request(app).post('/users').send({name: 'Alice'});
        expect(res.status).toBe(201);
      });
    });

  coverage_gaps:
    - {module: "AuthService", risk: "high", effort_hours: 8}

Quality Gates

Token budgets (mandatory):

• T1 ≤ 2k tokens (recommendation only)
• T2 ≤ 6k tokens (full strategy + scaffolding)
• T3 not implemented

Safety checks:

• No hardcoded credentials in test templates
• No PII in example data
• Framework versions are recent (within 2 years)

Auditability:

• All sources cited with access date = NOW_ET
• Effort estimates include methodology reference
• Test distribution rationale tied to architecture pattern

Determinism:

• Same inputs produce same percentage recommendations (±5%)
• Scaffolding templates are idempotent
• Gap calculations are reproducible

Validation checklist:

• Output JSON validates against schema
• Markdown renders without errors
• Code snippets are syntactically valid
• Total effort ≤ constraint time budget

Resources

Primary sources (accessed 2025-10-25):

1. Google Testing Blog: https://testing.googleblog.com/ Best practices, case studies, and emerging patterns from Google's testing infrastructure team.

2. Martin Fowler - Testing: https://martinfowler.com/testing/ Canonical testing patterns, pyramid model, and test doubles taxonomy.

3. Practical Test Pyramid: https://martinfowler.com/articles/practical-test-pyramid.html Detailed guide on test distribution, anti-patterns, and framework examples.

4. Microsoft Testing Patterns: https://learn.microsoft.com/en-us/dotnet/core/testing/ Official guidance for unit, integration, and performance testing in .NET ecosystems.

5. ISTQB Foundation Level: https://www.istqb.org/certifications/certified-tester-foundation-level International standard for testing terminology, lifecycle, and techniques.

Additional templates:

• See resources/test-pyramid-template.md for Markdown strategy template
• See examples/strategy-example.txt for complete workflow example

Related skills (future):

• performance-test-designer (for load/stress testing deep dive)
• mutation-testing-analyzer (for assessing test effectiveness)
• flaky-test-investigator (for debugging unstable tests)

End of SKILL.md