For complex systems with many services and environments, you need a deliberate network strategy for your Playwright tests. The goal is to balance realism (catching real issues) with stability and speed (keeping feedback loops fast).
Designing a Network Stubbing Strategy
A common approach is to use a pyramid of suites: some fully integrated against staging, some partially stubbed and some heavily mocked for edge cases. Playwright’s routing and network tools fit into this by letting you choose per suite how much to stub.
Example strategy:
- Smoke suite: minimal stubbing, runs against staging, focuses on key journeys
- Regression suite: mix of real and stubbed APIs for broader coverage
- Edge-case suite: heavy use of stubs to cover rare errors and timeouts
- Contract tests: separate tool checking API schemas and behaviours@smoke, @stubbed) so CI jobs can select appropriate suites for different pipelines.Revisiting your network strategy as architecture evolves ensures that tests stay aligned with the system’s risk profile and critical flows.
Common Mistakes
Mistake 1 — Having no clear boundary between stubbed and real tests
This confuses expectations.
❌ Wrong: Tests that sometimes hit real services and sometimes stub them, depending on who last edited the file.
✅ Correct: Define which suites are stubbed and which are integrated, and keep that behaviour consistent.
Mistake 2 — Never updating network strategy as the system grows
This causes blind spots.
❌ Wrong: Keeping the same test split even after major architecture changes.
✅ Correct: Periodically review suites and adjust where stubbing or integration is most valuable.