integration-test-generator

Integration & System Test Generator

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.

Use When

• Your code changes involve multiple services or layers (API ↔ Database, Service ↔ Service, UI ↔ API)
• You've modified API endpoints, database queries, or service-to-service communication
• You need end-to-end or cross-layer integration test coverage
• You're implementing user workflows that span multiple components
• You want to verify third-party service integrations
• You need to test performance, resilience, or concurrent scenarios

Overview

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.

Prerequisites

• Git repository with code changes staged or committed in the current branch
• Default branch available for comparison
• Code changes involving cross-layer interactions or external dependencies
• Existing integration test files (optional but recommended for pattern analysis)
• Access to API definitions, database schemas, or service contracts in code

Workflow

Step 1: Map Integration Points

• Identify API endpoints (REST, GraphQL, gRPC, webhooks) in changed code
• Extract database operations (queries, migrations, transactions)
• Detect service-to-service calls and event publishing
• Find component interactions and state management flows
• Identify third-party service integrations and external calls

Step 2: Analyze Code Changes

• Compare current branch against default branch
• Determine scope: new endpoints, modified logic, added services
• Extract request/response contracts, data schemas, error handling
• Identify authentication, authorization, and validation requirements

Step 3: Detect Integration Test Patterns

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:

• Integration test frameworks (Playwright, Cypress, Postman, pytest, RSpec, Mocha, etc.)
• Test organization and file structure
• Setup/teardown and fixture patterns
• Mock and stub strategies
• Data seeding and cleanup approaches
• Assertion patterns for async/event-driven scenarios

Step 4: Identify Integration Coverage Gaps

Analyze integration points for missing coverage:

• API Endpoints: Are contracts tested for happy path, errors, validation, auth?
• Database Operations: Are transactions, relationships, and migrations tested?
• Service Calls: Are timeouts, failures, fallbacks, and retries tested?
• Event Flows: Are pub/sub patterns, order, and missed events tested?
• User Workflows: Are multi-step journeys with state changes tested?
• Third-Party Integrations: Are external service failures handled and tested?

Step 5: Generate Integration Test Proposals

For each integration point, propose tests covering:

Test Scenario Types

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

For Each Proposed Test, Include:

• Integration point name and type (API, DB, Service call, Workflow)
• Scenario type (happy path, error handling, edge case, resilience, performance, security)
• Test setup requirements (fixtures, mocks, test data, environment)
• Test flow (steps through multiple layers)
• Expected behavior and assertions
• Cleanup and teardown requirements
• Estimated complexity (Low/Medium/High based on layers involved)

Step 6: Create Implementation Plan

Document:

• File location and test structure
• Integration test frameworks to use
• Mock/stub strategies for dependencies
• Test data preparation approach
• Parallelization and ordering considerations
• Performance benchmarks if applicable
• Priority for implementation (critical path first)

Inputs

• Current Branch: Must have staged or committed code changes
• Repository Access: To read both current and default branch code
• Integration Tests: Optional existing tests to analyze patterns

Outputs

1. Integration Points Summary

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]

2. Test Framework Detection

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)

3. Coverage Gap Analysis

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

4. Integration Test Proposals

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

5. Implementation Plan

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

Example Output

Given Code Changes

// 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" });
  }
}

Generated Integration Test Proposals

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)

Implementation Checklist

• Map all API endpoints in changed code
• Identify database operations and migrations
• Detect service-to-service calls and events
• Find third-party service integrations
• Scan for existing integration test files
• Analyze test framework and patterns
• Identify all integration coverage gaps
• Generate test proposals for each gap
• Organize proposals by scenario type and priority
• Create implementation plan with time estimates
• Define mock/stub strategies
• Document test data requirements

Integration Point Categories

1. API/HTTP Endpoints

Test REST, GraphQL, gRPC, and webhook APIs:

• Request validation and error responses
• Authentication and authorization
• Response contracts and schemas
• Error scenarios and status codes
• Concurrent request handling

2. Database Integration

Test schema integrity, transactions, and queries:

• Migration execution and rollback
• Query correctness and performance
• Transaction boundaries and rollback
• Concurrent access and locking
• Data relationships and constraints

3. Service-to-Service Communication

Test microservice interactions:

• Service contract compliance
• Timeout and retry behavior
• Circuit breaker patterns
• Event ordering and delivery
• Fallback and degradation strategies

4. Component Interaction

Test multiple components working together:

• State management across components
• Event flow and pub/sub patterns
• Dependency injection and wiring
• Memory leaks and resource cleanup

5. User Workflows & E2E

Test complete user journeys:

• Multi-step workflows with state
• Form submissions and validations
• Navigation and redirect flows
• Data persistence across steps
• Concurrent user interactions

6. Third-Party Integrations

Test external service dependencies:

• API contract compliance
• Error handling and retries
• Rate limiting and backoff
• Webhook delivery and ordering
• Credential and secret management

Notes

• Integration tests are slower but catch cross-layer bugs unit tests miss
• Prioritize happy path and critical error scenarios first
• Use realistic test data and environments
• Mock external dependencies to keep tests fast and reliable
• Consider test flakiness from timeouts and async operations
• Document mock/stub strategies for maintainability
• Run integration tests in CI/CD but separately from unit tests