lecture 7 of 160 completed

A policy for stubbing, not a habit

Stubbing makes tests fast and stable. Done without a policy it produces a green suite over a broken application.

What you'll learn

  • Why an unplanned stubbing habit hides real breakage
  • How to tier tests by how much they stub
  • How to keep a tier that would break on API drift

Picture a team that stubs almost every request. The suite is fast and steady for eight months. Then a backend release renames a field, every screen shows blank names in production, and all two hundred tests are green while support handles the complaints.

Nobody was careless. Each individual decision to stub was reasonable. What was missing was a policy, and writing that policy is senior work.

The trade, stated plainly. Stubbing replaces the server's answer with one you control. You gain speed, determinism, and access to states you cannot easily create. You lose the only thing that was checking whether your app and your server still agree.

full course

Keep reading with the full course

The Foundations track and the first lessons in each framework are free. This lesson needs full course access. A course plan includes all lessons for Playwright, Cypress and Selenium.

See course plans →