Testing Strategy Composer

name: "Testing Strategy Composer"
slug: testing-strategy-composer
description: "Compose comprehensive testing strategies spanning unit, integration, e2e, and performance tests with optimal coverage."
capabilities:
- analyze_system_architecture
- recommend_test_type_distribution
- generate_test_scaffolding
- identify_coverage_gaps
- create_execution_plans
inputs:
system_description:
type: string
description: "Text or architecture diagram describing the system under test"
required: true
tech_stack:
type: array
description: "List of technologies, frameworks, and languages"
required: true
constraints:
type: object
description: "Budget, time, or resource limitations"
required: false
existing_coverage:
type: object
description: "Current test metrics (lines covered, test count, types)"
required: false
outputs:
test_strategy:
type: markdown
description: "Complete testing strategy document with test pyramid recommendations"
test_scaffolding:
type: code
description: "Framework-specific code templates for each test type"
coverage_gaps:
type: json
description: "Identified untested areas and risk assessment"
execution_plan:
type: markdown
description: "Phased rollout timeline with effort estimates"
keywords:
- testing
- test-pyramid
- unit-tests
- integration-tests
- e2e-tests
- performance-tests
- test-strategy
- coverage
- quality-assurance
version: 1.0.0
owner: william@cognitive-toolworks
license: MIT
security:
pii: false
secrets: false
sandbox: recommended
links:
- https://testing.googleblog.com/
- https://martinfowler.com/testing/
- https://martinfowler.com/articles/practical-test-pyramid.html
- https://learn.microsoft.com/en-us/dotnet/core/testing/
- https://www.istqb.org/certifications/certified-tester-foundation-level

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:
3. system_description is non-empty string or parseable diagram
4. tech_stack contains at least one technology identifier
5. constraints (if provided) includes valid keys: budget, time, team_size
6. existing_coverage (if provided) has numeric metrics
7. Source freshness: All cited sources accessed on NOW_ET; verify links resolve
8. 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:
2. Identify architecture pattern (monolith, microservices, serverless, mobile, etc.)
3. Extract key components (API, database, UI, services, jobs)

4. Determine complexity level (simple/moderate/complex)

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

6. Unit tests (70%): Business logic, utilities, pure functions
7. Integration tests (20%): Database, API contracts, external services
8. E2E tests (10%): Critical user journeys, smoke tests

9. Adjust ratios based on architecture (e.g., API-only systems: 60/30/10)

10. Output initial recommendation:
    json { "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.

1. Map tech stack to testing frameworks:
2. JavaScript/Node.js → Jest, Mocha, Supertest, Playwright
3. Python → pytest, unittest, Selenium
4. Java → JUnit, Mockito, RestAssured
5. C# → xUnit, NUnit, SpecFlow

6. Consult Microsoft Testing Patterns

7. Generate framework-specific scaffolding:

8. Unit test template with arrange-act-assert pattern
9. Integration test template with setup/teardown
10. E2E test template for critical path
11. Performance test baseline (if applicable)

12. Reference Google Testing Blog for best practices

13. Identify coverage gaps:

14. Compare existing_coverage to targets
15. Calculate gap percentage per test type
16. Prioritize by risk (auth > payments > admin)

17. Output JSON with specific untested modules

18. Create phased execution plan:

19. Phase 1 (Week 1): High-risk unit tests
20. Phase 2 (Week 2): Integration tests for data layer
21. Phase 3 (Week 3): E2E critical paths
22. Phase 4 (Week 4): Performance baselines + refactor
23. Apply ISTQB Foundation principles (ISTQB)

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):

• 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