Design comprehensive test strategies with risk-informed prioritization (P0/P1/P2), test levels (unit/integration/E2E), mock strategies, and CI/CD integration. Creates Given-When-Then scenarios for all acceptance criteria, develops mock strategies for external dependencies, and plans CI/CD execution stages. Use during task planning before implementation to ensure comprehensive test coverage.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Design comprehensive test strategies with risk-informed prioritization (P0/P1/P2), test levels (unit/integration/E2E), mock strategies, and CI/CD integration. Creates Given-When-Then scenarios for all acceptance criteria, develops mock strategies for external dependencies, and plans CI/CD execution stages. Use during task planning before implementation to ensure comprehensive test coverage.
version
2
category
Quality
acceptance
{"all_acs_have_tests":"All acceptance criteria have test scenarios designed with Given-When-Then format, clear pass/fail criteria, and test data specifications","priorities_assigned":"All test scenarios assigned priority levels (P0/P1/P2) based on risk scores from risk-profile or AC criticality","mock_strategies_developed":"Mock strategies developed for all external dependencies (APIs, databases, services) with implementation guidance","cicd_integration_planned":"CI/CD test execution strategy planned with stages (pre-commit, PR, pre-deployment, production), parallelization, and coverage requirements"}
inputs
{"task_id":{"type":"string","required":true,"description":"Task identifier for test design (e.g., 'task-007')"},"task_file":{"type":"string","required":true,"description":"Path to task specification file"},"assessment_mode":{"type":"enum","required":false,"description":"Assessment timing (pre-implementation | retrospective)","default":"pre-implementation"},"risk_profile_file":{"type":"string","required":false,"description":"Path to risk profile file (for risk-informed prioritization)"}}
outputs
{"total_tests":{"type":"number","description":"Total number of test scenarios designed"},"p0_tests_count":{"type":"number","description":"Number of P0 (critical) tests"},"p1_tests_count":{"type":"number","description":"Number of P1 (high priority) tests"},"p2_tests_count":{"type":"number","description":"Number of P2 (medium priority) tests"},"unit_tests_count":{"type":"number","description":"Number of unit tests"},"integration_tests_count":{"type":"number","description":"Number of integration tests"},"e2e_tests_count":{"type":"number","description":"Number of end-to-end tests"},"estimated_execution_time_seconds":{"type":"number","description":"Estimated total test execution time in seconds"},"test_design_file":{"type":"string","description":"Path to generated test design document"}}
Design comprehensive test strategies before implementation using risk-informed prioritization, test level recommendations (unit/integration/E2E), mock strategies for dependencies, and CI/CD integration planning.
Purpose
Create test design documents that specify:
Test scenarios with Given-When-Then format for all acceptance criteria
Test levels (unit, integration, E2E) based on what's being tested
Test priorities (P0/P1/P2) based on risk scores and criticality
Mock strategies for external dependencies with implementation guidance
CI/CD integration with execution stages and coverage requirements
Key Innovation (BMAD Pattern):
Test design BEFORE implementation guides what tests to write
Performance: Response time, resource usage, scalability
Integration: Component interactions, service boundaries
Map to test levels:
What needs unit tests? (Logic, validation, algorithms)
What needs integration tests? (API, database, service interactions)
What needs E2E tests? (User journeys, critical workflows)
Consider technical constraints:
External dependencies to mock (APIs, payment, email)
Database interactions (test DB or mock?)
Async operations (promises, callbacks)
File I/O (temp directories)
Network calls (mock or test endpoints?)
Output: Test requirements identified per AC, categories mapped (happy path/error/edge/security/performance/integration), test levels determined (unit/integration/E2E), technical considerations noted
Halt Conditions: ACs too vague to test | Missing context
See:references/templates.md#step-1-output for complete format with detailed examples
Step 2: Design Test Scenarios
Purpose: Create specific test scenarios with Given-When-Then format, priorities, and test data
Actions:
For each test requirement from Step 1:
Write test scenario description:
Use Given-When-Then format for clarity (not BDD code, just format)
Specify exact inputs and expected outputs
Define clear pass/fail criteria
Include test data samples
Assign test level:
Unit, Integration, or E2E
Based on what's being tested (logic vs interaction vs journey)
Assign priority (risk-informed):
P0 if: Critical functionality, security, high-risk (score ≥6), data integrity
P1 if: Important functionality, medium-risk (score 3-5), core features
P2 if: Edge cases, low-risk (score 1-2), optional features
Specify test data requirements:
Valid samples (normal inputs)
Invalid samples (error scenarios)
Edge case values (boundaries, limits)
Security payloads (injection, XSS)
Identify dependencies:
What needs to be mocked? (external APIs, payment, email)
What requires real services? (database, file system)
What fixtures needed? (test data, mocks)
Output: Test scenarios with Given-When-Then format, test level assigned, priority assigned (P0/P1/P2 with risk linkage), test data specified, dependencies identified
Halt Conditions: Cannot define clear pass/fail criteria | Scenarios too ambiguous
Purpose: Calculate test counts, priorities, and execution time estimates
Actions:
Count tests by level:
Total unit tests
Total integration tests
Total E2E tests
Total all tests
Count tests by priority:
P0 (Critical) - must pass before merge
P1 (High) - should pass before merge
P2 (Medium) - can defer if needed
Estimate execution time:
Unit: 50ms average × count
Integration: 500ms average × count
E2E: 5s average × count
Total execution time
Calculate expected coverage:
Based on scenarios vs acceptance criteria
Critical path coverage (should be 100%)
Overall coverage estimate (based on scope)
Output: Test count summary (by level and priority), priority breakdown (P0/P1/P2 counts), estimated execution time (by level and total), expected coverage (overall and critical paths)
Halt Conditions: None (calculation always possible)
See:references/templates.md#step-5-output for complete summary examples
Step 6: Generate Test Design Document and Present Summary
Purpose: Generate complete test design document and present concise summary to user
Actions:
Load test design template:
Read .claude/templates/test-design.md (if exists)
Use default structure if template missing
Populate all sections:
Test summary (from Step 5)
Test scenarios by acceptance criterion (from Step 2)
Key test scenarios (security, functionality, performance)
Mock strategy summary
CI/CD integration summary
Risk-test mapping (if available)
Next steps guidance
Output: Complete test design document written to file, concise summary presented to user with test counts/priorities/mock strategy/CI-CD/risk mapping, clear next steps guidance
Halt Conditions: File write fails
See:references/templates.md#step-6-output for complete user-facing summary example and test design document template
Integration with Other Skills
After risk-profile: Risk profile identifies high-risk areas with P×I scores → test-design uses scores for prioritization (critical risks → P0 tests, high → P0/P1, medium/low → P2)
Before implementation: Test design complete with scenarios/mocks/CI-CD → Implementation writes tests following scenarios, uses mock strategies, achieves P0 tests first, targets 80%+ coverage
With trace-requirements: Test design provides scenarios mapped to ACs → trace-requirements verifies all scenarios implemented, all ACs covered by passing tests, coverage gaps identified
See:references/templates.md#integration-examples for complete workflows with data flow
Best Practices
Test-first approach (design before code) | Risk-informed prioritization (critical risks → P0 tests) | Appropriate test levels (unit for logic, integration for interactions, E2E for critical journeys) | Realistic mock strategies (mock external APIs, real DB test instances) | CI/CD integration (fast feedback loops) | Coverage vs quality (focus on meaningful scenarios, 100% for critical paths)
Common Pitfalls
Avoid: Too many E2E tests (slow/brittle) | Under-mocking (hitting real APIs) | Brittle tests (hard-coded values) | Ignoring test performance (slow suites) | Testing implementation details (private methods) | No CI/CD integration (manual only)
Instead: Unit test logic, E2E for critical journeys | Mock external dependencies | Use factories/fixtures | Keep unit <50ms, integration <500ms | Test public API/behavior | Automate in CI/CD
Configuration
Configure in .claude/config.yaml: Test coverage targets (overall/criticalPaths/newCode), test timeouts (unit/integration/e2e), assessment location
See:references/templates.md#configuration-examples for complete config.yaml, package.json scripts, jest.config.js
Reference Files
Detailed documentation in references/:
templates.md: All output formats (Step 0-6), complete test scenario examples (Given-When-Then), mock strategies (email service, database, JWT, payment API), CI/CD examples (GitHub Actions, GitLab CI, pre-commit hooks), complete test design document template, configuration examples, JSON output format
test-scenarios.md: Test scenario patterns (currently placeholder - see templates.md)
mock-strategies.md: Mock strategy patterns (currently placeholder - see templates.md)
cicd-integration.md: CI/CD integration patterns (currently placeholder - see templates.md)
test-examples.md: Test design examples (currently placeholder - see templates.md)
Version: 2.0 (Refactored for skill-creator compliance and Minimal V2 architecture)
Category: Quality
Depends On: risk-profile (optional but recommended for risk-informed prioritization)
Used By: trace-requirements (verifies test coverage of acceptance criteria)
