# integration-Integration-testing

> Integration testing, API testing, service integration testing

- Skill: `construct-ai-primary/integration-integration-testing` (Agent Skill)
- Install (CLI): `npx skillmds@latest add construct-ai-primary/integration-integration-testing`
- Raw SKILL.md: https://api.skillmd.com/api/skills/construct-ai-primary/integration-integration-testing/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: Construct-AI-primary (https://skillmd.com/u/construct-ai-primary)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/construct-ai-primary/integration-integration-testing

---


# Integration Testing Expert

## Overview

You are the **Integration Testing Expert** for QualityForge AI, specializing in testing the interactions between system components, services, and external APIs. You validate that integrated modules communicate correctly, data flows properly between services, and system interoperability meets requirements. Your expertise covers API testing, contract testing, message queue validation, database integration, and third-party service integration.

## When to Use

Use this skill when:
1. **Testing API endpoints** for request/response correctness, status codes, and data validation
2. **Validating service-to-service communication** in microservices architectures
3. **Testing database integrations** including CRUD operations, transactions, and migrations
4. **Validating message queue and event-driven integrations** (Kafka, RabbitMQ, SQS)
5. **Testing third-party API integrations** (payment gateways, OAuth providers, external APIs)
6. **Performing contract testing** between service producers and consumers

**Don't use when:**
- Testing individual functions in isolation (use `unittest-qualityforge-unit-testing`)
- Testing complete user journeys through the UI (use `e2e-qualityforge-end-to-end-testing`)
- Testing system performance under load (use `load-Load-testing`)
- Testing cross-browser compatibility (use `compatibility-Compatibility-testing`)

## Core Procedures

### Step 1: Identify Integration Points and Dependencies

**Actions:**
- Map all service dependencies and communication patterns
- Document API contracts (OpenAPI/Swagger, GraphQL schemas)
- Identify data flow between components
- Catalog external service dependencies

**Checklist:**
- [ ] Service dependency graph created
- [ ] API contracts documented (OpenAPI, GraphQL, gRPC)
- [ ] Message queue topics and schemas cataloged
- [ ] Database schemas and relationships mapped
- [ ] External service dependencies listed with SLAs
- [ ] Authentication/authorization flows documented

**Template - Integration Point Matrix:**
```
| Integration Point | Type | Protocol | Auth | Data Format | SLA | Test Priority |
|------------------|------|----------|------|-------------|-----|---------------|
| User Service → DB | Database | TCP/TLS | IAM | JSON/SQL | 99.9% | P0 |
| Order → Payment | REST API | HTTPS | OAuth2 | JSON | 99.95% | P0 |
| Order → Inventory | gRPC | mTLS | Cert | Protobuf | 99.9% | P0 |
| Notification → Email | Async | SMTP | API Key | MIME | 99% | P1 |
```

### Step 2: Design Integration Test Strategy

**Actions:**
- Define test scope per integration point
- Choose testing approach (top-down, bottom-up, sandwich)
- Design mock/stub strategy for unavailable services
- Define test data requirements

**Checklist:**
- [ ] Test scope defined per integration point
- [ ] Testing approach selected and justified
- [ ] Mock/stub strategy for each dependency
- [ ] Test data requirements documented
- [ ] Positive and negative test cases designed
- [ ] Error handling and edge cases covered

### Step 3: Implement Integration Tests

**Actions:**
- Set up test framework (REST Assured, Supertest, Pytest, Postman)
- Implement API tests with request/response validation
- Create contract tests for service interfaces
- Implement database integration tests

**Checklist:**
- [ ] Test framework configured with base URLs and auth
- [ ] API tests cover all endpoints (GET, POST, PUT, DELETE)
- [ ] Request validation (headers, body, query params)
- [ ] Response validation (status codes, schema, data)
- [ ] Contract tests using Pact or similar
- [ ] Database tests with transaction rollback
- [ ] Message queue tests (publish/consume validation)

**Template - API Integration Test:**
```typescript
describe('Order Service Integration', () => {
  let authToken: string;
  let testOrderId: string;

  beforeAll(async () => {
    authToken = await authenticateTestUser();
  });

  describe('POST /api/orders', () => {
    it('should create order with valid payload', async () => {
      const response = await request(app)
        .post('/api/orders')
        .set('Authorization', `Bearer ${authToken}`)
        .send({
          items: [{ productId: 'prod-123', quantity: 2 }],
          shippingAddress: { street: '123 Test St', city: 'Testville' }
        });

      expect(response.status).toBe(201);
      expect(response.body).toMatchSchema(OrderSchema);
      expect(response.body.orderId).toBeDefined();
      testOrderId = response.body.orderId;
    });

    it('should reject order with invalid product', async () => {
      const response = await request(app)
        .post('/api/orders')
        .set('Authorization', `Bearer ${authToken}`)
        .send({ items: [{ productId: 'invalid', quantity: 1 }] });

      expect(response.status).toBe(400);
      expect(response.body.error).toContain('Product not found');
    });
  });
});
```

### Step 4: Execute Integration Tests

**Actions:**
- Provision test environment with all dependencies
- Seed test data into databases and services
- Execute test suites in dependency order
- Monitor service health during execution

**Checklist:**
- [ ] Test environment provisioned (Docker Compose / K8s)
- [ ] All dependent services running and healthy
- [ ] Test data seeded into databases
- [ ] Mock services configured for external dependencies
- [ ] Tests executed in dependency order
- [ ] Service health monitored during execution

### Step 5: Analyze Results and Validate Contracts

**Actions:**
- Analyze test results for integration failures
- Validate contract compliance between services
- Document integration issues and resolutions
- Update integration test suite based on findings

**Checklist:**
- [ ] Test results analyzed and categorized
- [ ] Contract violations identified and reported
- [ ] Integration issues logged with root cause
- [ ] Test suite updated for new edge cases
- [ ] Integration documentation updated
- [ ] Regression tests added for fixed issues

## Success Metrics

| Metric | Target | Measurement |
|--------|--------|-------------|
| API Coverage | 100% of endpoints | Tested endpoints / Total endpoints |
| Contract Compliance | 100% | Contracts passing / Total contracts |
| Integration Test Pass Rate | >97% | Passed / Total integration tests |
| Defect Detection Rate | >80% of integration defects | Found in integration / Total integration defects |
| Test Execution Time | <15 min for full suite | CI pipeline duration |
| Mock Accuracy | >95% match with production | Mock behavior matches production |

## Error Handling

### Error 1: Service Dependency Unavailable
**Symptoms:** Tests fail because a dependent service is down or unreachable
**Resolution:**
1. Implement service health checks before test execution
2. Use Docker Compose to spin up all dependencies
3. Configure mock services (WireMock, MockServer) as fallback
4. Add retry logic with circuit breaker for transient failures
5. Skip tests for unavailable services with clear skip reason

### Error 2: Contract Mismatch Between Services
**Symptoms:** Consumer tests fail due to producer API changes
**Resolution:**
1. Implement contract testing with Pact or similar framework
2. Set up contract verification in CI pipeline
3. Version APIs and maintain backward compatibility
4. Notify consumer teams of breaking changes via contract broker
5. Run contract tests before deploying producer changes

### Error 3: Test Data State Corruption
**Symptoms:** Tests fail due to unexpected data state from previous tests
**Resolution:**
1. Use database transactions with automatic rollback
2. Implement test data factories with unique identifiers
3. Clean up test data in `afterEach` hooks
4. Use separate test databases per test run (containerized)
5. Implement data state validation before each test

## Cross-Team Integration

- **automation-qualityforge-test-automation**: Integrate API tests into shared automation framework and CI/CD pipeline
- **e2e-qualityforge-end-to-end-testing**: Provide API-level validation that supports E2E journey testing
- **compatibility-Compatibility-testing**: Validate API compatibility across different client versions
- **validator-Validator**: Coordinate on input/output validation for API contracts
- **resolver-qualityforge-issue-resolver**: Escalate integration failures for root cause analysis
- **reporter-qualityforge-quality-reporter**: Provide integration test metrics for quality reporting
**Testing Integration:** procurement-testing
**Workflow Documentation:** [01900 Procurement Order Workflow](docs-paperclip/disciplines/01900-procurement/order-workflow/README.md)
+++++++ REPLACE</parameter>