Contract and component tests

Contract tests lock API agreements between consumer and provider—request shape, status codes, headers, and schema—without spinning up the full system. Component tests render a UI slice (page section or widget tree) with realistic providers and assert user-visible behavior plus integration with immediate children, sitting between unit and E2E.

They shine when microservices or design systems evolve independently: contracts catch breaking changes early; component tests catch regressions in forms, tables, and modals faster than browser suites.

On interviews: contrast a Pact-style contract with a mocked unit test and explain when component tests replace—not duplicate—E2E.

Common pitfalls: contracts that mirror implementation trivia, components tested in isolation without router or query context they need, or oversized "component" tests that are really E2E.

The trade-off is narrower scope for speed—contracts and components miss cross-service choreography that only E2E reveals.

Checklist:

• State what a contract guarantees versus what it cannot.
• Mount components with realistic boundaries (data, routing, theme).
• Keep component tests focused on one behavioral slice.