The Meerako Testing Pyramid: Why Our 5.0★ Apps Don't Break

“

Meerako — Our 100% Satisfaction Guarantee is built on a foundation of 5.0★ quality and rigorous testing.

"We'll fix it later." "We don't have time to write tests." "Just ship it." These are three of the most expensive sentences in software development, and the cost usually surfaces months later as a production incident nobody saw coming.

Our 5.0★ rating isn't an accident — it's the result of a disciplined, engineering-first culture built around a specific belief: untested code is broken code, whether or not the bug has been found yet. We structure our automated testing around the Testing Pyramid, a strategy that dictates how testing effort gets allocated to catch bugs before they ever reach a user. The tooling underneath that strategy has shifted meaningfully in the last two years, too — Vitest hit 14 million weekly npm downloads in early 2026, up from under 4 million just two years prior, and Playwright has overtaken Cypress in weekly downloads as the default choice for new end-to-end suites. We've moved with that shift on new projects while keeping Jest where it's still the right call, and this post lays out exactly how and why.

• What the Testing Pyramid actually is, and why the shape of it matters.
• What each layer — unit, integration, and end-to-end tests — is actually checking for.
• The specific tools we use at each layer in 2026, and why we chose them over the alternatives.
• How this connects directly into our CI/CD pipeline, not as a separate afterthought step.
• What a real defect-cost curve looks like, and why catching bugs early is a financial decision, not just an engineering preference.

The Testing Pyramid's core idea: many small, fast tests at the base, progressively fewer, larger, and slower tests toward the top.

• Base (widest): unit tests — fast, cheap, run by the thousands.
• Middle: integration tests.
• Top (narrowest): end-to-end tests — slower, more expensive to run and maintain, used sparingly and deliberately.

What they check: a single, isolated piece of code — one function, one component — in complete isolation from everything else.

Our tools: Jest on established codebases, and increasingly Vitest on new projects. The shift matters in practice, not just on paper — Vitest typically runs three to five times faster than Jest thanks to native ESM support and Vite-powered module resolution, and it's now rated the highest-satisfaction testing tool in developer surveys, having gone from a newcomer to a genuine default in about two years. Jest, still the single most-downloaded test runner overall at roughly 32 million weekly downloads, remains our choice for React Native projects and any legacy codebase already built around Jest-specific plugins, where a migration wouldn't pay for itself.

A concrete example: for function add(a, b) { return a + b; }, the test is simply expect(add(2, 2)).toBe(4). For a React component, we test whether passing a specific name prop actually renders that name correctly.

Why they matter: unit tests run in seconds — we can execute thousands in a minute — and pinpoint exactly where something broke. This is the first line of defense, running automatically every time a developer commits, well before any human reviews the code.

What they check: whether two or more units work correctly together, not just correctly in isolation.

Our tools: Jest or Vitest (matching whichever the project's unit-test layer uses) plus React Testing Library.

A concrete example: clicking an "Add to Cart" button (one unit) should correctly update the Shopping Cart component's displayed count (a second unit) — testing the seam between them, not either piece alone.

Why they matter: most real bugs don't live inside a single function — they live at the boundaries where pieces connect, exactly where unit tests alone can't catch them.

What they check: the entire system, exercised the way a real user actually would — an automated script that opens a real browser, navigates a live site, and performs a full user flow.

Our tools: Playwright, as our default on new projects, with Cypress retained on a handful of older codebases where it's already deeply embedded. This isn't a marginal preference — Playwright communicates with browsers directly through the native DevTools Protocol, while Cypress runs its test code inside the browser itself, a fundamental architectural difference that shows up as real limitations for Cypress: no genuine multi-tab support, and no true cross-browser execution from a single runner. Playwright supports all three major browser engines — Chromium, Firefox, and WebKit — with true parallelism and no paid tier required to get it, better TypeScript support out of the box, and noticeably less flakiness in our own experience running both side by side across client projects.

A concrete example flow: navigate to the site, click login, enter test credentials, submit, and assert the page now shows a personalized welcome message — verifying frontend, backend, database, and authentication are all genuinely working together, not just individually correct.

Why they matter: this is the ultimate smoke test, run before and after every production deployment, proving the system works end to end from an actual user's perspective, not just in isolated unit-level assumptions.

1. CI/CD enforcement. No code merges unless 100% of unit and integration tests pass — our GitHub Actions pipeline enforces this automatically, with no manual override.
2. Tests travel with the code, not after it. Developers hand off features to QA with the tests already written, not as a separate task assigned later.
3. E2E tests double as demo scripts. They frequently form the backbone of our weekly Agile demos, proving to clients directly that a feature works in a real scenario, not just in a developer's local environment.
4. Playwright's trace viewer and video recordings get attached automatically to any failed CI run, so debugging a flaky-looking failure doesn't require reproducing it locally first — a real time-saver we didn't have with our older Cypress-only pipelines.

Teams sometimes invert this — writing mostly E2E tests because they feel most "realistic" — which produces a slow, brittle, expensive-to-maintain test suite that developers eventually start skipping under deadline pressure. The pyramid shape exists because unit tests catch the overwhelming majority of bugs cheaply and fast; E2E tests exist specifically for the smaller set of risks that only surface when the whole system runs together. A full E2E suite that takes twenty minutes to run doesn't just slow down CI — it changes developer behavior, because a slow feedback loop trains engineers to batch changes and test less frequently, which is the opposite of what you want from a testing strategy in the first place.

This isn't just an engineering philosophy — it's a cost argument, and a fairly stark one. A bug caught by a unit test during development costs a developer minutes to fix, in the same context, with the relevant code already open in their editor. The same bug, if it survives to a staging environment, costs meaningfully more — someone has to reproduce it, trace it back through code they may not have written, and re-test the fix. If it survives all the way to production, the cost compounds again: a support ticket, an engineering investigation, a hotfix deployment, and in the worst cases, real damage to user trust that no amount of fast patching fully repairs. We treat the pyramid's investment in cheap, fast, early-layer tests as directly protecting a client's budget, not just our own engineering pride — every hour spent writing a good unit test is an hour that prevents several hours of much more expensive downstream debugging.

The classic pyramid diagram is directionally right but rarely gives teams a concrete number to aim for, so here's roughly what we target on a typical mid-sized SaaS project: somewhere around 70% of the total test count as unit tests, 20% as integration tests, and the remaining 10% as end-to-end tests. On a codebase with a few thousand tests total, that might mean 2,000+ fast unit tests running in well under a minute, a few hundred integration tests covering component interactions and API contract behavior, and perhaps 50-100 E2E tests covering the handful of critical paths that actually matter — checkout, authentication, core CRUD flows for whatever the product's central object is. We don't chase a rigid ratio for its own sake, but when a project's test suite starts inverting toward more E2E tests than integration tests, that's a signal worth investigating, because it usually means engineers reached for a slow, expensive E2E test to verify something a cheap unit test could have caught just as reliably.

Testing implementation details instead of behavior. A unit test that breaks every time you refactor internal code without changing external behavior is testing the wrong thing — it should verify what the function or component does, not how it does it internally, or it becomes a maintenance burden that actively discourages healthy refactoring.

Flaky E2E tests that get ignored rather than fixed. Once a team starts treating a red E2E test as "probably just flaky, re-run it," the entire suite's credibility erodes fast, and genuine failures start slipping through re-runs along with the false positives. We treat flakiness as a bug in the test itself, not a fact of life to route around.

Skipping tests under deadline pressure "just this once." This is the single most common way a well-intentioned testing culture erodes over a few months — each skipped test feels justified in isolation, but the accumulated gap in coverage is exactly where the next production incident tends to live. Our CI gate exists specifically to remove this as a judgment call under pressure.

Our 100% Satisfaction Guarantee is possible because we have genuine confidence in the code we ship — and that confidence comes from a disciplined, automated testing strategy, not hope. Bugs caught in development cost a fraction of what the same bug costs once it's live in production. The Testing Pyramid, built today on a modern stack of Vitest, Jest, and Playwright, is our investment in avoiding that cost on your behalf.

Ready to build your product with a partner that is obsessed with quality?