Integration Testing Strategies for Microservices: Beyond Unit Tests

Unit tests are great. They’re fast, focused, and give you immediate feedback. But here’s the uncomfortable truth: your unit tests can all pass while your system is completely broken.

In microservices architectures, the real complexity isn’t within individual services - it’s in how they interact. A service that works perfectly in isolation can fail spectacularly when integrated with others. Network failures, serialization issues, version mismatches, timing problems - none of these show up in unit tests.

After years of building and testing distributed systems, I’ve learned that integration testing in microservices requires a completely different mindset than traditional monolithic applications.

The Integration Testing Challenge

In a monolithic application, integration testing is relatively straightforward:

1. Spin up your database
2. Start your application
3. Run your tests
4. Clean up

In microservices, you face:

• Multiple services running simultaneously
• Complex dependencies between services
• Different data stores for each service
• Network communication that can fail
• Eventually consistent data
• Version compatibility across services
• External dependencies you don’t control

Testing all of this is expensive, slow, and brittle. Unless you have a strategy.

The Testing Pyramid for Microservices

The traditional testing pyramid needs an update for microservices:

        /\
       /  \  E2E Tests (Few)
      /____\
     /      \
    / Integ. \ Integration Tests (Some)
   /__________\
  /            \
 /  Unit Tests  \ Unit Tests (Many)
/________________\

But in microservices, add another critical layer:

        /\
       /  \  E2E (Cross-Service)
      /____\
     /      \
    / Integ. \ Component Tests (Service-Level)
   /__________\
  /            \
 / Contract    \ Contract Tests (API Boundaries)
/_______________\
      /  \
     / Unit\ Unit Tests (Function-Level)
    /______\

Each layer serves a different purpose and makes different trade-offs.

Strategy 1: Contract Testing

Contract testing is your first line of defense against integration failures. Instead of testing the actual integration, you test that each service honors its contract.

Consumer-Driven Contracts

The consumer defines what it expects from the provider:

// order-service/tests/contracts/payment-service.contract.ts
describe('Payment Service Contract', () => {
  const provider = new Pact({
    consumer: 'order-service',
    provider: 'payment-service',
    port: 8080
  });

  beforeAll(() => provider.setup());
  afterAll(() => provider.finalize());

  describe('POST /payments', () => {
    it('processes valid payment', async () => {
      // Define the contract expectation
      await provider.addInteraction({
        state: 'user has sufficient balance',
        uponReceiving: 'a valid payment request',
        withRequest: {
          method: 'POST',
          path: '/payments',
          body: {
            orderId: '12345',
            amount: 99.99,
            currency: 'USD'
          }
        },
        willRespondWith: {
          status: 200,
          body: {
            transactionId: Matchers.uuid(),
            status: 'completed',
            amount: 99.99
          }
        }
      });

      // Test against the contract
      const client = new PaymentClient('http://localhost:8080');
      const response = await client.processPayment({
        orderId: '12345',
        amount: 99.99,
        currency: 'USD'
      });

      expect(response.status).toBe('completed');
      expect(response.transactionId).toBeDefined();
    });

    it('rejects insufficient funds', async () => {
      await provider.addInteraction({
        state: 'user has insufficient balance',
        uponReceiving: 'a payment request exceeding balance',
        withRequest: {
          method: 'POST',
          path: '/payments',
          body: {
            orderId: '12346',
            amount: 1000.00,
            currency: 'USD'
          }
        },
        willRespondWith: {
          status: 402,
          body: {
            error: 'insufficient_funds',
            message: Matchers.string()
          }
        }
      });

      const client = new PaymentClient('http://localhost:8080');

      await expect(
        client.processPayment({
          orderId: '12346',
          amount: 1000.00,
          currency: 'USD'
        })
      ).rejects.toMatchObject({
        status: 402,
        error: 'insufficient_funds'
      });
    });
  });
});

Provider Verification

The provider service verifies it meets all consumer contracts:

// payment-service/tests/contract-verification.ts
describe('Payment Service Provider Verification', () => {
  let app: Express;

  beforeAll(async () => {
    app = await startApp();
  });

  it('verifies all consumer contracts', async () => {
    const verifier = new Verifier({
      providerBaseUrl: 'http://localhost:3000',
      pactBrokerUrl: 'https://pact-broker.example.com',
      provider: 'payment-service',
      providerVersion: process.env.GIT_COMMIT,
      publishVerificationResult: true,

      // Set up test state
      stateHandlers: {
        'user has sufficient balance': async () => {
          await testDb.users.create({
            id: 'test-user',
            balance: 500.00
          });
        },
        'user has insufficient balance': async () => {
          await testDb.users.create({
            id: 'test-user',
            balance: 10.00
          });
        }
      }
    });

    await verifier.verifyProvider();
  });
});

Why Contract Testing Works

• Fast: No need to spin up all services
• Isolated: Test one integration at a time
• Clear failures: Know exactly which contract was broken
• Version safe: Verify compatibility before deployment
• CI/CD friendly: Runs quickly in pipelines

Strategy 2: Component Testing

Component tests treat each service as a black box and test it with all its real dependencies, but isolated from other services.

In-Process Component Tests

// user-service/tests/component/user-registration.test.ts
describe('User Registration Component Test', () => {
  let app: Express;
  let database: Database;
  let emailService: MockEmailService;

  beforeAll(async () => {
    // Real database (test instance)
    database = await setupTestDatabase();

    // Mock external services
    emailService = new MockEmailService();

    // Start real application
    app = await startApp({
      database,
      emailService
    });
  });

  afterAll(async () => {
    await teardownTestDatabase(database);
  });

  it('registers new user end-to-end', async () => {
    const response = await request(app)
      .post('/api/users/register')
      .send({
        email: 'test@example.com',
        password: 'SecurePass123!',
        name: 'Test User'
      })
      .expect(201);

    // Verify response
    expect(response.body.user).toMatchObject({
      email: 'test@example.com',
      name: 'Test User'
    });
    expect(response.body.user.id).toBeDefined();

    // Verify database state
    const savedUser = await database.users.findByEmail('test@example.com');
    expect(savedUser).toBeDefined();
    expect(savedUser.password).not.toBe('SecurePass123!'); // Hashed

    // Verify side effects
    expect(emailService.sentEmails).toContainEqual(
      expect.objectContaining({
        to: 'test@example.com',
        template: 'welcome'
      })
    );
  });

  it('handles duplicate email gracefully', async () => {
    // Create existing user
    await database.users.create({
      email: 'existing@example.com',
      password: 'hashed',
      name: 'Existing User'
    });

    await request(app)
      .post('/api/users/register')
      .send({
        email: 'existing@example.com',
        password: 'SecurePass123!',
        name: 'Test User'
      })
      .expect(409);

    // Verify no duplicate created
    const users = await database.users.findAll({
      email: 'existing@example.com'
    });
    expect(users).toHaveLength(1);

    // Verify no email sent
    expect(emailService.sentEmails).toHaveLength(0);
  });
});

Using Testcontainers

For more realistic testing, use actual service dependencies with containers:

// order-service/tests/component/order-processing.test.ts
import { GenericContainer } from 'testcontainers';

describe('Order Processing Component Test', () => {
  let app: Express;
  let postgresContainer: StartedTestContainer;
  let redisContainer: StartedTestContainer;

  beforeAll(async () => {
    // Start real PostgreSQL
    postgresContainer = await new GenericContainer('postgres:14')
      .withExposedPorts(5432)
      .withEnvironment({
        POSTGRES_DB: 'orders_test',
        POSTGRES_USER: 'test',
        POSTGRES_PASSWORD: 'test'
      })
      .start();

    // Start real Redis
    redisContainer = await new GenericContainer('redis:7')
      .withExposedPorts(6379)
      .start();

    const dbUrl = `postgresql://test:test@${postgresContainer.getHost()}:${postgresContainer.getMappedPort(5432)}/orders_test`;
    const redisUrl = `redis://${redisContainer.getHost()}:${redisContainer.getMappedPort(6379)}`;

    app = await startApp({
      databaseUrl: dbUrl,
      redisUrl: redisUrl
    });

    // Run migrations
    await runMigrations(dbUrl);
  });

  afterAll(async () => {
    await postgresContainer.stop();
    await redisContainer.stop();
  });

  it('processes order with inventory check', async () => {
    // Setup inventory
    await request(app)
      .post('/api/inventory')
      .send({ productId: 'prod-1', quantity: 10 });

    // Create order
    const orderResponse = await request(app)
      .post('/api/orders')
      .send({
        items: [
          { productId: 'prod-1', quantity: 2 }
        ],
        customerId: 'cust-1'
      })
      .expect(201);

    const orderId = orderResponse.body.order.id;

    // Verify inventory was decremented
    const inventoryResponse = await request(app)
      .get('/api/inventory/prod-1')
      .expect(200);

    expect(inventoryResponse.body.quantity).toBe(8);

    // Verify order status
    const orderStatus = await request(app)
      .get(`/api/orders/${orderId}`)
      .expect(200);

    expect(orderStatus.body.status).toBe('confirmed');
  });
});

Strategy 3: Service Virtualization

When testing against external services is too slow, expensive, or unreliable, use service virtualization:

// tests/helpers/mock-services.ts
import { WireMock } from 'wiremock-client';

export class MockPaymentGateway {
  private wiremock: WireMock;

  constructor(private baseUrl: string) {
    this.wiremock = new WireMock(baseUrl);
  }

  async setupSuccessfulPayment(orderId: string, amount: number) {
    await this.wiremock.stub({
      request: {
        method: 'POST',
        url: '/charge',
        bodyPatterns: [{
          matchesJsonPath: {
            expression: '$.orderId',
            equalTo: orderId
          }
        }]
      },
      response: {
        status: 200,
        jsonBody: {
          transactionId: `txn-${orderId}`,
          status: 'success',
          amount,
          timestamp: new Date().toISOString()
        },
        headers: {
          'Content-Type': 'application/json'
        }
      }
    });
  }

  async setupFailedPayment(reason: string) {
    await this.wiremock.stub({
      request: {
        method: 'POST',
        url: '/charge'
      },
      response: {
        status: 402,
        jsonBody: {
          error: 'payment_failed',
          reason
        },
        fixedDelayMilliseconds: 100
      }
    });
  }

  async setupTimeoutScenario() {
    await this.wiremock.stub({
      request: {
        method: 'POST',
        url: '/charge'
      },
      response: {
        status: 500,
        fixedDelayMilliseconds: 30000 // 30 second delay
      }
    });
  }

  async verifyPaymentAttempts(expectedCount: number) {
    const requests = await this.wiremock.getRequests({
      method: 'POST',
      url: '/charge'
    });

    expect(requests.length).toBe(expectedCount);
  }
}

// Usage in tests
describe('Order Service with Payment Gateway', () => {
  let mockGateway: MockPaymentGateway;

  beforeAll(async () => {
    mockGateway = new MockPaymentGateway('http://localhost:8089');
  });

  it('retries failed payments with exponential backoff', async () => {
    await mockGateway.setupFailedPayment('card_declined');

    await request(app)
      .post('/api/orders')
      .send({
        items: [{ productId: 'prod-1', quantity: 1 }],
        paymentMethod: 'card'
      })
      .expect(402);

    // Verify retry attempts
    await mockGateway.verifyPaymentAttempts(3); // Initial + 2 retries
  });

  it('handles payment gateway timeout', async () => {
    await mockGateway.setupTimeoutScenario();

    const response = await request(app)
      .post('/api/orders')
      .send({
        items: [{ productId: 'prod-1', quantity: 1 }],
        paymentMethod: 'card'
      })
      .expect(503);

    expect(response.body.error).toBe('payment_service_unavailable');
  });
});

Strategy 4: Test Data Management

Managing test data across multiple services is challenging. Here’s how to do it right:

Test Data Builders

// tests/builders/order.builder.ts
export class OrderBuilder {
  private order: Partial<Order> = {
    status: 'pending',
    items: [],
    createdAt: new Date()
  };

  withCustomer(customerId: string): this {
    this.order.customerId = customerId;
    return this;
  }

  withItem(productId: string, quantity: number, price: number): this {
    this.order.items!.push({ productId, quantity, price });
    return this;
  }

  withStatus(status: OrderStatus): this {
    this.order.status = status;
    return this;
  }

  withTotal(total: number): this {
    this.order.total = total;
    return this;
  }

  async build(): Promise<Order> {
    // Calculate total if not set
    if (!this.order.total && this.order.items!.length > 0) {
      this.order.total = this.order.items!.reduce(
        (sum, item) => sum + (item.price * item.quantity),
        0
      );
    }

    // Save to database
    return await database.orders.create(this.order as Order);
  }

  buildObject(): Order {
    return { ...this.order, id: 'test-order-123' } as Order;
  }
}

// Usage
const order = await new OrderBuilder()
  .withCustomer('cust-1')
  .withItem('prod-1', 2, 29.99)
  .withItem('prod-2', 1, 49.99)
  .withStatus('confirmed')
  .build();

Fixture Management

// tests/fixtures/index.ts
export class TestFixtures {
  private cleanupTasks: Array<() => Promise<void>> = [];

  async createUser(overrides?: Partial<User>): Promise<User> {
    const user = await database.users.create({
      email: `test-${randomUUID()}@example.com`,
      name: 'Test User',
      ...overrides
    });

    this.cleanupTasks.push(() => database.users.delete(user.id));
    return user;
  }

  async createProduct(overrides?: Partial<Product>): Promise<Product> {
    const product = await database.products.create({
      name: 'Test Product',
      price: 29.99,
      stock: 100,
      ...overrides
    });

    this.cleanupTasks.push(() => database.products.delete(product.id));
    return product;
  }

  async cleanup(): Promise<void> {
    for (const task of this.cleanupTasks.reverse()) {
      await task();
    }
    this.cleanupTasks = [];
  }
}

// Usage in tests
describe('Order Tests', () => {
  let fixtures: TestFixtures;

  beforeEach(() => {
    fixtures = new TestFixtures();
  });

  afterEach(async () => {
    await fixtures.cleanup();
  });

  it('creates order with products', async () => {
    const user = await fixtures.createUser();
    const product = await fixtures.createProduct({ price: 19.99 });

    const order = await createOrder({
      userId: user.id,
      items: [{ productId: product.id, quantity: 2 }]
    });

    expect(order.total).toBe(39.98);
  });
});

Strategy 5: Testing Eventual Consistency

Microservices often rely on eventual consistency. Your tests need to handle this:

// tests/helpers/async-assertions.ts
export async function waitFor<T>(
  assertion: () => Promise<T>,
  options: {
    timeout?: number;
    interval?: number;
    timeoutMessage?: string;
  } = {}
): Promise<T> {
  const timeout = options.timeout || 5000;
  const interval = options.interval || 100;
  const start = Date.now();

  while (true) {
    try {
      return await assertion();
    } catch (error) {
      if (Date.now() - start > timeout) {
        throw new Error(
          options.timeoutMessage ||
          `Timeout waiting for condition: ${error.message}`
        );
      }
      await sleep(interval);
    }
  }
}

// Usage
it('propagates inventory updates across services', async () => {
  // Update inventory in inventory service
  await inventoryService.updateStock('prod-1', 50);

  // Wait for event propagation to catalog service
  await waitFor(
    async () => {
      const product = await catalogService.getProduct('prod-1');
      expect(product.availableStock).toBe(50);
      return product;
    },
    {
      timeout: 10000,
      timeoutMessage: 'Inventory update did not propagate to catalog service'
    }
  );
});

Testing Event-Driven Workflows

describe('Order Fulfillment Saga', () => {
  it('completes happy path', async () => {
    // Start the saga
    const orderId = await orderService.createOrder({
      customerId: 'cust-1',
      items: [{ productId: 'prod-1', quantity: 2 }]
    });

    // Wait for inventory reservation
    await waitFor(async () => {
      const inventory = await inventoryService.getReservations(orderId);
      expect(inventory).toHaveLength(1);
      expect(inventory[0].quantity).toBe(2);
    });

    // Wait for payment processing
    await waitFor(async () => {
      const payment = await paymentService.getPayment(orderId);
      expect(payment.status).toBe('completed');
    });

    // Wait for shipping label creation
    await waitFor(async () => {
      const shipment = await shippingService.getShipment(orderId);
      expect(shipment.trackingNumber).toBeDefined();
    });

    // Verify final order status
    await waitFor(async () => {
      const order = await orderService.getOrder(orderId);
      expect(order.status).toBe('shipped');
    });
  });

  it('handles payment failure with compensation', async () => {
    // Setup payment to fail
    await paymentService.setNextPaymentToFail();

    const orderId = await orderService.createOrder({
      customerId: 'cust-1',
      items: [{ productId: 'prod-1', quantity: 2 }]
    });

    // Wait for compensation (inventory release)
    await waitFor(async () => {
      const reservations = await inventoryService.getReservations(orderId);
      expect(reservations).toHaveLength(0); // Released
    });

    // Verify order marked as failed
    await waitFor(async () => {
      const order = await orderService.getOrder(orderId);
      expect(order.status).toBe('payment_failed');
    });
  });
});

Strategy 6: Performance Testing Integration Points

Integration tests should also verify performance characteristics:

describe('API Performance', () => {
  it('handles concurrent order creation', async () => {
    const concurrentRequests = 50;
    const startTime = Date.now();

    const orders = await Promise.all(
      Array.from({ length: concurrentRequests }, (_, i) =>
        createOrder({
          customerId: `cust-${i}`,
          items: [{ productId: 'prod-1', quantity: 1 }]
        })
      )
    );

    const duration = Date.now() - startTime;

    // Verify all orders created
    expect(orders).toHaveLength(concurrentRequests);

    // Verify reasonable performance
    expect(duration).toBeLessThan(5000); // Should complete in under 5 seconds

    // Verify no duplicate IDs
    const orderIds = new Set(orders.map(o => o.id));
    expect(orderIds.size).toBe(concurrentRequests);
  });

  it('maintains response times under load', async () => {
    const measurements: number[] = [];

    for (let i = 0; i < 100; i++) {
      const start = Date.now();
      await getProduct('prod-1');
      measurements.push(Date.now() - start);
    }

    const p95 = percentile(measurements, 95);
    const p99 = percentile(measurements, 99);

    expect(p95).toBeLessThan(100); // 95th percentile under 100ms
    expect(p99).toBeLessThan(200); // 99th percentile under 200ms
  });
});

Strategy 7: Testing Cross-Service Transactions

Distributed transactions require careful testing:

describe('Distributed Transaction Handling', () => {
  it('commits across all services on success', async () => {
    const orderId = randomUUID();

    // Start distributed transaction
    await transactionCoordinator.begin(orderId);

    // Participate in transaction from multiple services
    await inventoryService.reserveStock(orderId, 'prod-1', 2);
    await paymentService.holdFunds(orderId, 59.98);
    await shippingService.reserveCapacity(orderId);

    // Commit all
    await transactionCoordinator.commit(orderId);

    // Verify all committed
    expect(await inventoryService.isReserved(orderId)).toBe(true);
    expect(await paymentService.isCharged(orderId)).toBe(true);
    expect(await shippingService.isScheduled(orderId)).toBe(true);
  });

  it('rolls back all services on failure', async () => {
    const orderId = randomUUID();

    await transactionCoordinator.begin(orderId);

    await inventoryService.reserveStock(orderId, 'prod-1', 2);
    await paymentService.holdFunds(orderId, 59.98);

    // Simulate shipping failure
    await shippingService.setNextOperationToFail();

    await expect(
      shippingService.reserveCapacity(orderId)
    ).rejects.toThrow();

    // Rollback
    await transactionCoordinator.rollback(orderId);

    // Verify all rolled back
    await waitFor(async () => {
      expect(await inventoryService.isReserved(orderId)).toBe(false);
      expect(await paymentService.isCharged(orderId)).toBe(false);
    });
  });
});

Best Practices

1. Test Isolation

Each test should be independent:

describe('User Service', () => {
  beforeEach(async () => {
    await cleanDatabase();
    await seedRequiredData();
  });

  it('test 1', async () => {
    // This test starts with clean state
  });

  it('test 2', async () => {
    // This test also starts with clean state
    // Not affected by test 1
  });
});

2. Meaningful Assertions

// Bad - too vague
expect(response.status).toBe(200);

// Good - specific and meaningful
expect(response).toMatchObject({
  status: 200,
  body: {
    order: {
      id: expect.stringMatching(/^ord-/),
      status: 'confirmed',
      total: 129.97,
      items: expect.arrayContaining([
        expect.objectContaining({
          productId: 'prod-1',
          quantity: 3
        })
      ])
    }
  }
});

3. Test Error Scenarios

describe('Order Service Error Handling', () => {
  it('handles database connection loss', async () => {
    // Simulate database failure
    await database.disconnect();

    await expect(
      createOrder({ items: [] })
    ).rejects.toMatchObject({
      code: 'SERVICE_UNAVAILABLE',
      retryable: true
    });
  });

  it('handles partial service failure', async () => {
    // Payment service is down
    await paymentService.simulateOutage();

    const response = await request(app)
      .post('/api/orders')
      .send({ items: [{ productId: 'prod-1', quantity: 1 }] })
      .expect(503);

    expect(response.body).toMatchObject({
      error: 'service_unavailable',
      service: 'payment',
      retryAfter: expect.any(Number)
    });
  });
});

4. Use Test Tags

describe('Order Service', () => {
  // Fast tests
  describe('[unit]', () => {
    it('calculates order total', () => {
      // Pure logic test
    });
  });

  // Moderate speed
  describe('[integration]', () => {
    it('saves order to database', async () => {
      // Database test
    });
  });

  // Slow tests
  describe('[e2e]', () => {
    it('completes full order workflow', async () => {
      // Full integration test
    });
  });
});

// Run specific suites
// npm test -- --testNamePattern="\[unit\]"
// npm test -- --testNamePattern="\[integration\]"

Continuous Integration Strategy

Fast Feedback Loop

# .github/workflows/pr-checks.yml
name: PR Checks

on: [pull_request]

jobs:
  fast-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run unit tests
        run: npm test -- --testNamePattern="\[unit\]"
      - name: Run contract tests
        run: npm run test:contracts

  integration-tests:
    runs-on: ubuntu-latest
    needs: fast-tests
    steps:
      - uses: actions/checkout@v3
      - name: Run integration tests
        run: npm test -- --testNamePattern="\[integration\]"

  e2e-tests:
    runs-on: ubuntu-latest
    needs: integration-tests
    steps:
      - uses: actions/checkout@v3
      - name: Run E2E tests
        run: npm run test:e2e

Parallel Execution

// jest.config.js
module.exports = {
  maxWorkers: '50%', // Use half available CPU cores
  testTimeout: 30000,
  setupFilesAfterEnv: ['./tests/setup.ts'],

  projects: [
    {
      displayName: 'unit',
      testMatch: ['**/__tests__/unit/**/*.test.ts'],
      testEnvironment: 'node'
    },
    {
      displayName: 'integration',
      testMatch: ['**/__tests__/integration/**/*.test.ts'],
      testEnvironment: 'node',
      globalSetup: './tests/integration-setup.ts',
      globalTeardown: './tests/integration-teardown.ts'
    }
  ]
};

Common Pitfalls to Avoid

1. Testing Implementation Details

// Bad - coupled to internals
expect(orderService['_cache'].has(orderId)).toBe(true);

// Good - test observable behavior
const order = await orderService.getOrder(orderId);
expect(order).toBeDefined();

2. Flaky Tests

// Bad - timing dependent
await createOrder();
await sleep(100); // Hope this is enough time
const order = await getOrder();

// Good - explicit waiting
await createOrder();
await waitFor(async () => {
  const order = await getOrder();
  expect(order.status).toBe('confirmed');
});

3. Shared Test State

// Bad - tests affect each other
let sharedUserId: string;

it('creates user', async () => {
  sharedUserId = await createUser();
});

it('updates user', async () => {
  await updateUser(sharedUserId); // Depends on previous test
});

// Good - independent tests
it('creates and updates user', async () => {
  const userId = await createUser();
  await updateUser(userId);
});

Tools and Libraries

Essential tools for integration testing microservices:

• Pact - Contract testing
• Testcontainers - Containerized dependencies
• WireMock - Service virtualization
• SuperTest - HTTP assertions
• Docker Compose - Multi-service orchestration
• k6 - Load testing
• Pact Broker - Contract management

Conclusion

Integration testing in microservices is complex, but with the right strategies:

1. Contract tests catch breaking changes early
2. Component tests verify service behavior in isolation
3. Service virtualization makes external dependencies manageable
4. Good test data management keeps tests maintainable
5. Async helpers handle eventual consistency
6. Performance tests ensure scalability

The goal isn’t to test everything everywhere - it’s to have confidence that your services work together correctly. Start with contract tests, add component tests for critical paths, and use E2E tests sparingly for the most important flows.

Your integration test suite should give you confidence to deploy to production, not slow down development to a crawl.

---

Part of the Developer Skills series. Build distributed systems you can trust.

Integration testing is where theoretical architecture meets practical reality. Get it right, and you can move fast with confidence. Get it wrong, and you’ll spend your days debugging production issues that never showed up in testing.