Siddhant DevalAuthor
Senior Full-Stack Engineer·Oct 13, 2026·13 min read
Testing Strategy: Contracts, Integration Boundaries, and E2E Scope
In a micro-frontend system, the boundary between teams is an API — test it like one. Unit tests stay local, contract tests guard boundaries, and E2E tests cover critical paths only. This article redraws the testing pyramid for distributed frontend systems.
Technical Series
Micro-Frontend Architecture
Part 7 of 9
Testing Strategy: Contracts, Integration Boundaries, and E2E Scope
A micro-frontend is not a smaller app — it is a domain boundary enforced at the deployment layer. If you can't explain the business capability it owns, you haven't drawn the boundary yet.
The default response to "how do we test a micro-frontend system" is to write more end-to-end tests. All remotes are deployed to a shared staging environment. Playwright starts a browser, navigates through the entire user journey, and asserts the expected result. When a test fails, it could be the Checkout remote, the Catalog remote, the shell's routing, the auth service, the API gateway, or the network between any of them. The test tells you something is wrong. It does not tell you whose code caused it, when the regression was introduced, or what the contractual expectation was.
In a micro-frontend system, the boundary between teams is an API. Test it like one: with a contract. Unit tests stay local and fast. Contract tests guard the boundary on every PR. E2E tests cover only the critical paths — the top 3–5 user journeys where orchestration failure is the highest risk.
1. The MFE Testing Pyramid
The standard testing pyramid (many unit tests, some integration, few E2E) applies to MFEs but with a critical addition: contract tests occupy the layer between integration and E2E.

Expand
2. Unit Tests: Per-Remote, Fully Isolated
Unit tests in a micro-frontend system are identical to unit tests in any React application — they test a single component or hook in isolation, with mocked dependencies. The only MFE-specific rule: a remote's unit tests must never import from another remote's source code.
typescript
Pro Tip & Optimization
Use MSW (Mock Service Worker) to mock API calls in unit and integration tests. MSW intercepts at the network level — your component code never needs to know it is running in a test environment. This means your tests exercise the same code path as production, including error handling in fetch calls.
3. Integration Tests: The Remote-in-Shell Pattern
Integration tests mount a remote application inside a minimal host shell — exercising the remote's component tree, routing, and event handling without deploying to a real environment.
typescript
The integration test specifically exercises:
- The remote's routing (does
/checkout/cartrender the correct component?) - The remote's API integration (does it call the correct endpoints?)
- The remote's event contracts (does it dispatch the correct Custom Events?)
4. Consumer-Driven Contract Testing with Pact
4.1 What Contract Testing Guards
A contract test defines the expectation of a consumer (the host, which imports
checkout/Cart) against the provider (the checkout remote, which exposes Cart). If the provider changes its exposed API in a way that breaks the consumer's expectation, the provider's CI pipeline fails — before that change reaches a shared environment.The key property: contract tests catch breaking changes at the provider's CI stage, not at the E2E stage after deployment. This shifts risk discovery from hours to minutes.
4.2 Writing the Consumer Contract
typescript
4.3 Verifying the Provider Contract
typescript
4.4 The Contract Lifecycle in CI

Expand
bash
5. Type Contracts as Build-Time Integration Tests
From Part 4,
@module-federation/dts-plugin generates and distributes TypeScript declaration files. These type bundles are not just developer convenience — they are executable integration tests:typescript
bash
The shell's CI pipeline fails with a clear error — before the checkout remote is deployed. No E2E test run is required. No staging environment is needed.
Crucial Requirement
Run
tsc --noEmit as a dedicated CI step after consumeTypes downloads the latest remote type bundles. Treat dts compilation errors as integration failures — they are evidence that a provider changed a contract without coordinating with its consumers.6. E2E Scope Discipline
6.1 The E2E Anti-Pattern
E2E tests are expensive: slow to run (60–300 seconds per test), brittle to infrastructure (network timeouts, shared staging data), and wide in failure scope (any service in the chain can cause failure). In a micro-frontend system with 5 remotes, the number of possible failure sources in an E2E test grows multiplicatively.
The correct scope for E2E tests in an MFE system is orchestration — testing that the shell correctly loads remotes, that navigation between remotes works, and that the critical user journeys succeed end-to-end. Component behavior and API integration belong in unit and contract tests.
typescript
Pro Tip & Optimization
If your E2E test suite has more than 15 tests, audit it: every test that could be a contract test or an integration test should be downgraded. E2E tests for MFE systems should exist in the tens, not hundreds.
7. Visual Regression Testing at the Remote Boundary
CSS bleed — where one remote's styles leak into another's rendered output — is a correctness problem that unit and contract tests cannot catch, but E2E tests are too slow to run on every PR. Visual regression testing at the component level fills this gap:
typescript
Running this in the Catalog remote's CI (without the shell's global stylesheet loaded) isolates any visual regression to the Catalog remote itself, before CSS from the composition layer can interfere.
Summary
| Testing Layer | Scope | Trigger | Tool | Target Count |
|---|---|---|---|---|
| Unit | Per-component, per-hook | Every commit | Vitest / Jest | Hundreds |
| Integration | Remote in minimal shell | Every PR | Testing Library + MSW | Tens |
| Contract (Pact) | Remote exposed API | Every PR (both sides) | Pact v12 | Tens |
| Type Contract | TypeScript dts bundle | Host build | tsc --noEmit | Zero errors |
| Visual Regression | Component isolated | Every PR | Playwright CT | Per-component |
| E2E | Critical journeys, orchestration | Pre-release, nightly | Playwright | 5–15 |
What's Next
In Part 8, we solve the style isolation problem — ranking every CSS isolation mechanism by isolation strength, explaining when Shadow DOM is worth the interoperability cost, and defining what should and should not cross a design system boundary. Part 8 → Styling Isolation and Design System Distribution
References
Research & Synthesis Note
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.
#Micro-Frontends#Testing#Contract Testing#Pact#E2E#Playwright#CI/CD
Technical Series
Micro-Frontend Architecture
Part 7 of 9