Testing Strategies

Test Structure (Arrange-Act-Assert)

describe("OrderService", () => {
  describe("createOrder", () => {
    it("creates an order with valid items and returns order ID", async () => {
      const repo = new InMemoryOrderRepository();
      const service = new OrderService(repo);
      const input = { customerId: "c1", items: [{ productId: "p1", quantity: 2 }] };

      const result = await service.createOrder(input);

      expect(result.id).toBeDefined();
      expect(result.status).toBe("pending");
      expect(result.items).toHaveLength(1);
      const saved = await repo.findById(result.id);
      expect(saved).toEqual(result);
    });

    it("rejects order with empty items", async () => {
      const service = new OrderService(new InMemoryOrderRepository());

      await expect(
        service.createOrder({ customerId: "c1", items: [] })
      ).rejects.toThrow("Order must have at least one item");
    });
  });
});

Name tests by behavior, not method name. Each test should be independent and self-contained.

Full runnable code for each technique below lives in reference.md (sibling file).

Contract Testing (Pact)

Contract tests verify that consumer expectations match provider capabilities without requiring both services to be running. Use a Pact mock provider to record the consumer's expected request/response, then replay it against the real provider in CI. Full Pact example: see reference.md.

Snapshot Testing

import { render } from "@testing-library/react";

it("renders the user profile card", () => {
  const { container } = render(
    <UserCard user={{ name: "Alice", email: "alice@example.com", role: "admin" }} />
  );

  expect(container).toMatchSnapshot();
});

it("renders the order summary with inline snapshot", () => {
  const summary = formatOrderSummary(mockOrder);

  expect(summary).toMatchInlineSnapshot(`
    "Order #123
    Items: 3
    Total: $45.99
    Status: Pending"
  `);
});

Use inline snapshots for small outputs. Review snapshot diffs carefully during code review.

Property-Based Testing

import fc from "fast-check";

describe("sortUsers", () => {
  it("always returns the same number of elements", () => {
    fc.assert(
      fc.property(
        fc.array(fc.record({ name: fc.string(), age: fc.nat(120) })),
        (users) => {
          const sorted = sortUsers(users, "name");
          return sorted.length === users.length;
        }
      )
    );
  });
});

Assert algorithmic invariants (length preserved, output sorted, idempotence) rather than specific outputs. A second invariant — "output is actually sorted for any input" — is in reference.md.

Integration Test with Test Containers

Spin up real dependencies in containers (e.g. PostgreSqlContainer("postgres:16")) so integration tests exercise the genuine data layer instead of mocks. Start the container in beforeAll, migrate, run assertions against the real DB, and stop it in afterAll (allow a generous timeout, e.g. 60s, for container startup). Full Postgres example: see reference.md.

Test Doubles

function createMockEmailService(): EmailService {
  const sent: Array<{ to: string; subject: string }> = [];
  return {
    send: async (to, subject, body) => { sent.push({ to, subject }); },
    getSent: () => sent,
  };
}

const emailService = createMockEmailService();
const service = new NotificationService(emailService);
await service.notifyUser("user-1", "Welcome");
expect(emailService.getSent()).toHaveLength(1);
expect(emailService.getSent()[0].subject).toBe("Welcome");

Anti-Patterns

• Testing implementation details instead of behavior
• Sharing mutable state between tests (no beforeEach reset)
• Writing tests that depend on execution order
• Mocking everything instead of using real dependencies for integration tests
• Ignoring flaky tests instead of fixing the root cause
• Testing trivial getters/setters while missing edge cases

Checklist

• Tests organized by behavior, not by method or file
• Each test follows Arrange-Act-Assert structure
• Contract tests verify inter-service API compatibility
• Snapshot tests reviewed during code review (not blindly updated)
• Property-based tests cover invariants for algorithmic code
• Integration tests use test containers for real dependencies
• Test doubles are minimal and behavior-focused
• CI fails on flaky test detection