From integration-test-generator
Analyze API endpoints, databases, and service interactions to generate integration and system test proposals with cross-layer scenarios
How this skill is triggered — by the user, by Claude, or both
Slash command
/integration-test-generator:integration-test-generatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Analyzes code changes for API endpoints, database operations, service interactions, and user workflows. Generates comprehensive integration and system test proposals by comparing the current branch against the default branch.
Analyzes code changes for API endpoints, database operations, service interactions, and user workflows. Generates comprehensive integration and system test proposals by comparing the current branch against the default branch.
This skill reviews code changes targeting integration points: REST/GraphQL APIs, database migrations and queries, component dependencies, event flows, and user workflows. It compares against the default branch to identify integration coverage gaps, analyzes existing integration test patterns, and generates prioritized proposals for integration and system tests covering happy paths, error handling, edge cases, and resilience scenarios.
Search repository for integration test files:
Frontend E2E: *.e2e.ts, *.integration.test.ts, *.spec.ts (with Playwright/Cypress patterns)
Backend Integration: test_*.py (with fixture patterns), *_integration_test.go, *.integration.spec.ts
API Testing: *.postman.json, *.rest, *.http, test_*.py (with requests patterns)
Database: *_migration.sql, test_*_db.py, *.migration.ts
Load Testing: k6/ folder, *.jmx files, gatling/ folder
Extract and document:
Analyze integration points for missing coverage:
For each integration point, propose tests covering:
| Scenario | Description | Example |
|---|---|---|
| Happy Path | Valid data flows through all layers correctly | POST /api/users → validation → DB save → response 201 |
| Error Handling | Invalid/error inputs handled at each layer | Invalid auth token → 401, Database constraint violated → 409 |
| Edge Case | Boundary conditions across layers | Empty result set, concurrent updates, race condition |
| Resilience | Service failures, timeouts, retries, fallbacks | Third-party API timeout → use cache, database unavailable → exponential backoff |
| Performance | Load, throughput, response time under expected volume | 1000 concurrent requests → < 500ms response time |
| Security | Auth, authorization, data isolation, injection prevention | SQL injection attempt blocked, unauthorized user denied access |
Document:
API Endpoints Found: [count]
- GET /api/users (new)
- POST /api/orders (modified)
Database Operations: [count]
- migration_001_users_table
- userRepository.find()
Service Calls: [count]
Event Flows: [count]
Third-Party Integrations: [count]
Frontend E2E: Playwright v1.40+
Backend Integration: pytest v7.0+ with fixtures
API Testing: Postman, Supertest
Database: TypeORM migrations
Load Testing: Not configured (recommended: k6)
Untested Integration Points:
- POST /api/orders → insufficient error handling tests
- Service call to payment provider → no timeout/retry tests
- Database transaction rollback → not tested
Total Coverage Gaps: 3
Critical Gaps (blocking production): 1
Integration Point: POST /api/orders
Type: API → Database → External Service
Proposal 1: Happy Path (Medium priority)
├─ Setup: Valid order data, authenticated user, mocked payment service
├─ Flow: POST request → validate → save to DB → call payment API → return 201
├─ Assertions: Order in DB, payment service called, response includes order ID
└─ Complexity: Medium
Proposal 2: Payment Service Timeout (High priority)
├─ Setup: Valid order, payment service timeout simulation
├─ Flow: POST request → validate → save to DB → payment timeout → retry → fallback
├─ Assertions: Order marked pending, retry attempted, notification sent
└─ Complexity: High
Proposal 3: Database Constraint Violation (Medium priority)
├─ Setup: Order with duplicate reference, database constraint
├─ Flow: POST request → validate → DB constraint error → rollback → return 409
├─ Assertions: DB unchanged, error response returned, no external calls made
└─ Complexity: Medium
Phase 1 (High Priority - Week 1):
- Happy path test for POST /api/orders
- Error handling for validation failures
- Database transaction rollback scenario
Estimated Time: 16 hours
Frameworks: Supertest + Jest
Phase 2 (Medium Priority - Week 2):
- Payment service timeout and retry scenarios
- Service failure fallback mechanisms
- Concurrent order placement race condition
Estimated Time: 20 hours
Frameworks: Supertest + Jest, Nock for HTTP mocking
Phase 3 (Performance - Week 3):
- Load test: 1000 concurrent orders
- Throughput benchmark (orders/sec)
- Database connection pooling validation
Estimated Time: 8 hours
Frameworks: k6 or Apache JMeter
Setup Required:
- Test database with schema loaded
- Mock payment service provider
- Test data factory for orders/users
- Environment-based configuration for endpoints
// New API endpoint in api/orders.ts
export async function createOrder(req: Request, res: Response) {
const { userId, items, paymentMethodId } = req.body;
// Validate request
if (!userId || !items?.length) {
return res.status(400).json({ error: "Invalid request" });
}
// Save order to database
const order = await Order.create({ userId, items, status: "pending" });
try {
// Call payment service
const paymentResult = await paymentService.charge(
paymentMethodId,
order.total,
);
await order.update({ status: "confirmed", paymentId: paymentResult.id });
res.status(201).json(order);
} catch (error) {
await order.update({ status: "failed" });
res.status(402).json({ error: "Payment failed" });
}
}
Test Suite: POST /api/orders Integration Tests
1. Happy Path: Should create and confirm order with successful payment (High)
Setup:
- Authenticated user with valid payment method
- Mock payment service configured for success
- Test database with schema loaded
Flow:
1. POST /api/orders with valid order data
2. Service validates input
3. Order saved to database with 'pending' status
4. Payment service called and succeeds
5. Order status updated to 'confirmed'
6. Response returns 201 with order data
Assertions:
- Response status is 201
- Response includes complete order with ID
- Order in database with status 'confirmed'
- Payment service called exactly once
- Payment ID stored in order
Complexity: Medium (3 layers: API, Database, External Service)
2. Validation Error: Should reject invalid order data (Medium)
Setup:
- Invalid order data (missing items, invalid userId)
- No database changes expected
Flow:
1. POST /api/orders with missing required fields
2. Service validates input
3. Returns 400 error
Assertions:
- Response status is 400
- No order created in database
- Payment service not called
- Error message is descriptive
Complexity: Low (single layer: API validation)
3. Payment Service Timeout: Should handle failed payment gracefully (High)
Setup:
- Valid order data
- Mock payment service configured to timeout after 5 seconds
- Transaction rollback capability
Flow:
1. POST /api/orders with valid data
2. Order saved with 'pending' status
3. Payment service called but times out
4. Catch error, update order to 'failed'
5. Return 402 Payment Required
Assertions:
- Response status is 402
- Order in database with status 'failed'
- No payment ID in order
- Error notification sent (email/webhook)
- Order remains in database (can be retried)
Complexity: High (error handling, timeout simulation, state management)
4. Concurrent Orders: Should handle concurrent requests safely (Medium)
Setup:
- Same user placing 2 orders simultaneously
- Database connection pool configured
Flow:
1. Two concurrent POST /api/orders requests
2. Both process simultaneously
3. Both orders saved correctly
4. Both payments processed in order
Assertions:
- Both orders created in database
- Each order has unique ID
- Both payment requests received
- Response time acceptable even with concurrency
Complexity: High (concurrency, database locking, race conditions)
5. Database Constraint Violation: Should handle duplicate order references (Low)
Setup:
- Order with duplicate reference ID
- Database constraint defined
Flow:
1. POST /api/orders with duplicate reference
2. Database constraint violation occurs
3. Transaction rolls back
4. Service returns 409 Conflict
Assertions:
- Response status is 409
- Only one order in database
- Payment service not called
- Error includes constraint violation info
Complexity: Medium (transaction management, error handling)
Test REST, GraphQL, gRPC, and webhook APIs:
Test schema integrity, transactions, and queries:
Test microservice interactions:
Test multiple components working together:
Test complete user journeys:
Test external service dependencies:
npx claudepluginhub lmaon2466/levar-marketplace --plugin integration-test-generatorProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.