The recurring sprint problem
One pattern I've seen repeatedly in sprints:
Automation doesn't fail because tests are hard.
It fails because dependencies aren't ready on time.
What actually happens mid-sprint
- Backend APIs are still evolving
- Data contracts are not finalized
- Third-party services are unstable
Result: automation spills into the next sprint.
Shift-left does not mean waiting for the backend
Shift-left is not about waiting.
It's about starting earlier without dependencies.
With Playwright, teams unblock themselves using:
- Network interception
- Response stubbing
- Backend behavior mocking
This lets automation move in parallel with development — not after it.
Visual overview

Interception
Used when you want visibility into real traffic.
await page.route("**/api/users", (route) => {
console.log(route.request().method());
route.continue();
});
Use it for
- Inspecting headers & payloads
- Observing real request behavior
- Debugging request / response flow
Limitations
- Depends on backend availability
- Not suitable for early sprint automation
Stubbing
Used when UI logic matters more than backend state.
await page.route("**/api/products", (route) => {
route.fulfill({
status: 200,
body: JSON.stringify({ products: mockData }),
});
});
Why teams prefer stubs
- Deterministic and fast
- No backend dependency
- Great for UI rendering & business rules
- Extremely CI-friendly
Mocking
Used when UI depends on stateful backend behavior.
await page.route("**/api/orders/**", async (route) => {
const orderId = route.request().url().split("/").pop();
const response =
orderId === "123"
? { status: "shipped" }
: { status: "processing" };
await route.fulfill({
status: 200,
body: JSON.stringify(response),
});
});
Why mocking is powerful
- Supports create → read → update flows
- Full control over backend behavior
- Ideal for complex UI journeys
Choosing the right approach
Early sprint: Mock APIs
UI validation: Stub responses
Error handling: Intercept & simulate failures
E2E confidence: Use real APIs selectively
Why this matters
- Prevents sprint spillovers
- Gives faster feedback to developers
- Keeps CI predictable
- Enables true parallel development
E2E tests still matter — but not everything needs to be E2E.
Pro tip
Version-control stubs/mocks as fixtures.
When APIs are ready:
- Replace
route.fulfill()withroute.continue() - Keep test logic unchanged
This makes your automation future-proof and easy to evolve.
Closing thought
Shift-left testing isn't about shortcuts.
It's about making automation a first-class citizen in the sprint — not an afterthought.