Loading page
About this tool
Plan unit, integration and end-to-end test ratios and see the runtime, CI cost and flakiness each mix produces.
This planner splits a test suite across unit, integration and end-to-end layers — the test pyramid popularised by Mike Cohn and Martin Fowler — and computes what each mix actually costs: serial and wall-clock runtime, billed CI minutes, monthly spend, and the probability a run fails on flaky tests alone (modelled as independent failures, 1 − Π(1 − p)^n). It is for tech leads and QA engineers deciding how many tests of each kind a suite should carry before the feedback loop or the CI bill gets out of hand.
Open Test Pyramid Ratio Planner on AltFTool — it loads instantly in your browser.
Enter the values you already know.
Fine-tune the options to match your scenario.
Read the result and use it in your planning or reporting.
Converts a ratio into wall-clock feedback time, billed worker-minutes and a monthly bill — the numbers a mix actually produces.
Applies per-layer flake rates to show expected flaky failures per run and the chance a whole run goes red for no real reason.
Names the shape you have built — pyramid, trophy, or ice-cream cone — including the case where the count looks fine but the runtime is E2E-dominated.
There is no single correct ratio — the classic pyramid illustration is roughly 70% unit, 20% integration and 10% end-to-end, from Mike Cohn's Succeeding with Agile. The principle behind it is what matters: push tests to the cheapest layer that can catch the failure, because unit tests run in milliseconds while E2E tests run in tens of seconds and flake more.
It is the inverted pyramid: more end-to-end tests than unit tests. It produces slow feedback (E2E tests are commonly hundreds of times slower than unit tests), high flake exposure, and failures that are hard to localise because one broken behaviour trips dozens of full-stack tests.
No — parallel workers shorten wall-clock time, but CI providers bill per worker-minute, so total billed minutes stay roughly the same as the serial runtime. Parallelism buys faster feedback, not a smaller bill; only removing or speeding up tests reduces cost.
More than their rate suggests, because failure chances compound across the suite: 100 E2E tests that each flake 2% of the time give a (1 − 0.98^100) ≈ 87% chance that at least one fails per run, before any real bug. That is why suites concentrate flake-prone tests in a small E2E layer and quarantine or retry known flakes.