Integration Test Guide

Purpose

Use this skill to move a project from implementation toward verified delivery. Focus on integration reality: environments, dependencies, test data, observability, performance targets, and release readiness.

Relationship to Implementation Verification

Use implementation-verification before this skill when generated code claims to be complete. This skill assumes basic build/runtime/browser smoke checks have already been done or explicitly marked as not verified.

Integration Test Workflow

1. Identify critical user journeys and service workflows.
2. Map external dependencies: database, cache, message broker, third-party APIs, auth, files, scheduled jobs.
3. Read the confirmed project structure so source test scripts use the approved paths, defaulting to scripts/test/integration/ for integration scripts and scripts/perf/ for performance scripts.
4. Define test environments and data setup.
5. Produce integration test cases before execution.
6. Define API/service integration scenarios.
7. Define failure scenarios: timeout, retry, duplicate request, partial failure, stale cache, message replay.
8. Produce an integration test plan, test case list, test data plan, and gate checklist.
9. Stop and request user approval before executing integration tests.

Integration Test Cases

Before executing integration tests, produce test cases with:

• Case id.
• Business scenario.
• Preconditions.
• Test data.
• Steps.
• Expected result.
• Related API/service/module.
• External dependency.
• Priority.
• Execution type: manual, API collection, automated test, or script.

Cover at least:

• Critical happy paths.
• Authentication and authorization.
• Validation failures.
• Not-found and duplicate submission.
• Transaction boundary or consistency behavior.
• Cache behavior when applicable.
• Message retry/replay when messaging exists.
• External dependency timeout/failure when applicable.

Performance Test Workflow

1. Identify performance-critical scenarios.
2. Produce performance test scenarios before execution.
3. Define baseline metrics: throughput, latency percentiles, error rate, CPU, memory, database load, cache hit rate, queue lag.
4. Define load model: users, requests per second, data volume, duration, ramp-up.
5. Define pass/fail criteria.
6. Define test tool direction: k6, JMeter, Gatling, or team-standard tool.
7. Define bottleneck analysis and report format.
8. Stop and request user approval before executing performance tests.

Performance Test Cases

Before executing performance tests, produce scenarios with:

• Scenario id.
• Business scenario.
• Endpoint/workflow.
• Data volume.
• Virtual users or request rate.
• Ramp-up strategy.
• Duration.
• Think time when applicable.
• Success criteria.
• Failure threshold.
• Metrics to collect.
• Required monitoring.

Cover at least:

• Login/auth flow when relevant.
• Core query/list page.
• Core create/update transaction.
• Permission-protected operation.
• Data-volume-sensitive query.
• Batch/export/import when in scope.

Release Readiness

Check:

• Required artifacts exist and have been reviewed.
• Implementation verification evidence exists for generated code and critical web flows.
• Integration tests cover critical workflows.
• Performance targets are explicit.
• Observability exists for key paths.
• Configuration and secrets are separated from code.
• Database migration and rollback are defined.
• Deployment and rollback steps are documented.

Output Format

Produce concise Markdown artifacts:

• Integration test plan.
• Integration test cases.
• Test data plan.
• Integration test execution report after execution.
• Performance test plan.
• Performance test cases.
• Performance test execution report after execution.
• Release readiness checklist.
• Open risks and blocking issues.

Default script locations:

• Integration test scripts: scripts/test/integration/
• Performance test scripts: scripts/perf/
• Deployment scripts and release helpers: scripts/deploy/

Default raw output locations:

• Integration test raw outputs: reports/integration/
• Performance test raw outputs, including JMeter HTML reports, .jtl files, k6 summaries, and Gatling reports: reports/performance/

Keep scripts/ for source scripts and executable test definitions only. Do not put generated HTML reports, logs, result files, dependency folders, or screenshots under scripts/.

After producing the integration test plan, integration test cases, and test data plan, stop and request explicit user review. Do not execute integration tests or proceed to performance testing until the user approves these artifacts.

After executing integration tests, produce an execution report and stop for user review before moving to performance testing.

After producing the performance test plan and performance test cases, stop and request explicit user review. Do not execute performance tests or proceed to release readiness until the user approves these artifacts.

After executing performance tests, produce an execution report and stop for user review before moving to release readiness.

After producing the release readiness checklist, stop and request explicit user review. Do not mark the project ready for release until the user approves the release readiness artifact.