Testing Strategy: Unit, Integration, and Playwright E2E Without an Inverted Pyramid
How to build meaningful coverage, what to unit test, and which journeys deserve Playwright in CI.
Ali Mortazavi
Founder, Paradise Code
Tests buy repeatable confidence, not coverage percentages
Line coverage alone does not create quality. The right question: if this path breaks, do we learn before users do? A test pyramid means pure logic gets cheap unit tests, boundaries get integration checks, and E2E is reserved for critical journeys.
Teams that E2E everything build slow, brittle CI; teams that only unit test miss real integration failures.
Unit tests for decision logic
Pricing, authorization, form validation, date/money transforms, and reducers are ideal unit targets. Separate them from I/O so they run in milliseconds without a browser or database. If a unit test must mock half of Nest, your module boundary is wrong.
Name tests by business behavior, not function names. When code changes tomorrow, behavior should still hold.
Integration at real boundaries
For APIs, tests that hit real HTTP against a running app or Nest module and touch a test database catch wiring bugs. Validate OpenAPI contracts here. For frontend, component tests with accessible roles (Testing Library) cover interactions without full E2E cost.
Keep test data buildable and cleanable. Dependence on a hand-made DB snapshot kills the suite by month two.
Playwright for money and trust paths
Focus E2E on signup, login, checkout, content publish, and sensitive RBAC paths—not every button. Write each scenario from the user’s view: “a buyer can complete an order,” not “Modal opens.”
Stability beats quantity: wait on stable roles/text, not random timeouts; isolate data between tests; retry only for known environmental flakes—not to hide bugs.
Data, environments, and secrets in CI
The E2E environment should be production-like with controlled seeds. Mock or sandbox external services so you do not create real charges or brittle rate limits. Keep test secrets separate from production secrets.
Store failure artifacts—trace, video, screenshot—in CI. Without them, E2E debugging is guesswork.
Ownership and signal in the team
Every flaky test is debt; fix it or quarantine it with an owner. Unowned red tests train people to ignore CI. In PRs, require tests related to the change—not a promise to “write them later.”
Review monthly: which E2E still earns its keep, where unit coverage is thin, which production path has no safety net. Testing strategy is a living product.
Frequently asked questions
What coverage percentage is “good”?
There is no magic number. Set targets on high-risk modules and measure escaped bugs, not vanity metrics.
Are UI snapshots useful?
For narrow visual contracts, yes; for large DOM trees they go brittle fast. Prefer behavioral assertions.
Run E2E on every PR or nightly?
Smoke the critical paths on PRs; run the broader suite nightly or on main. Balance feedback speed and coverage depth.
Playwright or Cypress?
Both are capable; Playwright is often simpler for multi-browser/multi-context modern CI. Choose by team skill and suite stability.
Insights
Need these ideas implemented in your product?
Paradise Code supports you from consult to full delivery.