Back to All News

Front-end testing pyramid: how to get your tests in order and not break the bank

Article date

09 12 2025

Article Author

Dmitry Golovatenko

Reading Time

5 minutes

Why do we need a testing pyramid?
Most bugs don't come from major flaws, but from little things: the amount was calculated incorrectly, the button stopped responding, the list didn't update. If you only test as a user, the tests will be long and fragile. If you only test the "internals," you may miss out on real-world scenarios. The pyramid is a balance between "quick and cheap" and "real-life-like," expressed in layers: unit/component, integration/contract, E2E, and visual regression/a11y/perf.
What does the pyramid consist of
1) Base: small checks of "bricks" - unit/component
We check small pieces: functions, simple components, individual rules.
  • Why: catch errors cheaply and quickly (low cost / fast feedback).
  • What we check: calculations, validations, reactions to events (pure logic, component rendering).
  • Examples: price format, field validation, tab switching.
  • Important: minimum dependencies (no network, no real DOM).
2) The middle layer: "parts together" — integration/contract
We look at how the modules work in conjunction: screen + data + error handling.
  • Why: we make sure that the parts "connect" (wiring).
  • What we check: a stateful component, exchange with the API via stubs (API stubs / MSW), compliance with agreements with the backend (API contract).
  • Examples: product list with pagination, order form with submission and error message.
  • Option: in critical places — contract tests (checking schemas/versions).
3) Top: end-to-end scenarios "like a user" — E2E
We go through the entire path in a real browser.
  • Why: we protect key business processes (happy path / critical flow).
  • What we check: navigation, input, server responses in a real environment (real browser, real backend/stage).
  • Examples: logging in to an account, making a purchase, and placing an order.
  • The rule: there aren't many of them, but they "insure" the business.
Separately: the appearance shouldn't "creep" — visual regression/a11y/perf
We periodically compare whether the layout has changed and whether accessibility and speed have been affected.
  • Visual regression: comparing screenshots of key screens/components.
  • A11y (accessibility): contrast, focus, keyboard navigation.
  • Performance: key metrics like LCP/INP/CLS.
Volume guideline:
  • «Bricks» (unit/component tests) — ~60%
  • «Parts together» (integration/contract tests) — ~25%
  • «End-to-end scenarios» (E2E tests) — ~10%
  • «Appearance» and other (visual regression, accessibility, and performance: visual regression/a11y/perf) — ~5%

This is not mathematics, but common sense: the higher up the pyramid, the more expensive and slower the tests are.
Typical errors
  • Inverted pyramid: almost everything is a long scenario. Result: slow builds, "fake" falls, and wasted nerves.
  • Too many "screenshots": comparing pictures instead of the essence. Any little thing "colours" the tests.
  • Unpredictable scenarios: the test depends on time, random data, or the network — it's either green or red.
  • We don't test what's important: dozens of tests for small details and none for payment or authorisation.
What's the benefit of a good strategy?
  • Fewer bugs in production. Critical paths are closed with short, stable checks.
  • Faster releases. Most tests are fast; long ones don't slow everyone down.
  • The team is calmer. Tests help, not hinder.
Principles that work
  • 1. Start with the simple. If an error can be caught by a small check, catch it there.
  • 2. Test behaviour, not "internals". The user "sees" that the button has saved data — this is what we check.
  • 3. Make tests predictable. Fix time, clean data, don't get tied to randomness.
  • 4. A short list of "vital" scenarios. 10-20 pieces per product is most often enough.
  • 5. Appearance — selectively. On key screens and design system elements.
A small implementation checklist
  • Identify critical paths: login, purchase, form submission, payments.
  • Break them down into "bricks": where you can test quickly and locally.
  • Add a couple of "links": screen + data + errors.
  • Save the best for last: 6-10 end-to-end scenarios "as a user".
  • Agree with your team: "done" includes both code and tests; new features require new tests.
  • Monitor metrics: how many tests "falsely" fail, how long the build takes.
Quality culture
Tests are not a "mandatory duty," but a business insurance. It helps:
  • a short template in tasks: "what has changed" → "how it is tested";
  • a shared catalog of screen examples (such as "component showcase") so that everyone can see how it should look;
  • regular reviews: once a sprint, check the stability and speed metrics.
Conclusion:
The testing pyramid is common sense, designed into a clear scheme. More quick checks at the bottom, a bit of "user checks" at the top - and the product becomes predictable. You put out fires less, release updates more often, and look at changes more calmly.

The company JSC "ROOT CODE" offers not only the development and support of websites, but also professional solutions in the field of information security. We help customers build protection at all levels - from technical infrastructure to organisational processes.