playbooks

home / skills / shotaiuchi / dotclaude / test-integration

test-integration skill

/dotclaude/skills/test-integration

This skill helps you create and validate integration tests across components, APIs, databases, and end-to-end flows to ensure cross-boundary correctness.

npx playbooks add skill shotaiuchi/dotclaude --skill test-integration

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.0 KB
---
name: test-integration
description: >-
  Integration test creation. Apply when writing tests that verify component
  interactions, API contract compliance, database transactions, and
  end-to-end data flow across boundaries.
user-invocable: false
---

# Integration Tests

Write integration tests that verify interactions across component boundaries.

## Test Creation Checklist

### Component Interaction
- Test communication between modules through real interfaces
- Verify dependency injection wiring produces correct collaborators
- Check event propagation across component boundaries
- Validate callback and listener invocation order
- Confirm proper lifecycle management between components

### API Contract Verification
- Test request/response format compliance with specifications
- Verify HTTP status codes for success, error, and edge cases
- Check header handling (authentication, content-type, caching)
- Validate pagination, filtering, and sorting parameters
- Test versioning and backward compatibility of endpoints

### Database Transaction Testing
- Verify CRUD operations produce correct persistent state
- Test transaction rollback on failure conditions
- Check concurrent access and locking behavior
- Validate migration scripts apply cleanly on test data
- Confirm cascade operations (delete, update) work correctly

### End-to-End Flow
- Trace data from input through all processing layers to output
- Verify data transformation accuracy at each boundary
- Test complete user workflows spanning multiple services
- Check that error states propagate correctly across layers
- Validate cleanup and resource release after flow completion

## Output Format

Report test plan with priority ratings:

| Priority | Description |
|----------|-------------|
| Must | Critical integration paths that verify system correctness |
| Should | Important cross-boundary flows for common scenarios |
| Could | Additional integration scenarios for edge conditions |
| Won't | Out of scope or better covered by unit/e2e tests |

Overview

This skill helps you design and produce integration tests that verify interactions across component boundaries, APIs, databases, and end-to-end flows. It provides a focused checklist and a prioritized reporting format to turn architectural concerns into concrete test plans. Use it to ensure components collaborate correctly and high-value cross-system paths are covered.

How this skill works

I inspect component interaction patterns, API contracts, database transaction behavior, and full data flows to generate targeted integration tests. For each area I produce test cases that exercise real interfaces, validate contracts and transactional guarantees, and trace data through all processing layers. I also assign priority ratings (Must/Should/Could/Won't) so you know which tests to implement first.

When to use it

  • When multiple modules must communicate through real interfaces rather than mocks
  • When verifying API contract compliance, status codes, headers, pagination, or versioning
  • When changes touch database schema, migrations, transactions, or cascading behavior
  • When validating end-to-end user workflows that traverse services and layers
  • When adding or refactoring dependency injection, event wiring, or lifecycle management

Best practices

  • Prefer real interfaces and lightweight test doubles only for external third parties
  • Start with Must-paths that guarantee system correctness before adding Should/Could scenarios
  • Keep tests deterministic: seed data, isolate transactions, and clean up resources after each run
  • Validate API contracts with both happy paths and representative error cases, including headers and status codes
  • Test transactions for rollback and concurrent access; include migration verification in CI

Example use cases

  • Verify that a service call triggers database updates and pub/sub events in the correct order (Must)
  • Confirm API endpoints preserve response shape, headers, and pagination after a version bump (Should)
  • Test that failed operations correctly roll back transactions and leave no partial state (Must)
  • Trace a full user checkout flow across frontend, order service, payment gateway mock, and inventory updates (Must)
  • Add edge-case scenarios for rate limits, sorting/filtering combinations, and unusual header combinations (Could)

FAQ

How do you decide Must vs Should vs Could?

Classify a scenario as Must if its failure breaks core system correctness or data integrity. Should is important for common user journeys. Could covers edge or low-impact flows.

Should integration tests replace unit tests?

No. Integration tests complement unit tests by validating collaboration between components; keep both for comprehensive coverage.