How many tests are enough? The test pyramid without dogma
The question “how many tests do we need?” does not have a number for an answer. A suite with one thousand tests can be worse than one with two hundred if the thousand take three hours to run, fail regularly, and nobody reads them. What matters is not the size of the suite, but the level at which each concern is verified.
The test pyramid is a simple model for layering tests. In simplified form, it distinguishes unit, integration or API, and UI tests. A larger share of checks should be at the lower, generally faster levels, with a smaller share in more expensive end-to-end scenarios. It is not a fixed ratio but a guide for designing the suite.
Common problems that need to be solved
A common reason for high costs and slow runs is that the suite verifies too many things through the user interface.
This is understandable. A UI test is close to what a customer does, and designing it does not require knowledge of every internal detail of the application. Such a test, however, often needs to start a browser, prepare a user and data, move through several screens, and wait for rendering. It tends to be slower and more sensitive to the network, data, or page layout, and even a change that does not alter functionality can affect it.
If you verify twenty discount-coupon combinations by clicking through the entire shopping cart every time, the result can be a long run and high maintenance costs.
How to address it: what belongs at each level
Unit tests—calculations and rules. These cover isolated pieces of logic, such as calculating prices, VAT, and discounts, validating formats, or handling state transitions. They usually provide fast feedback, and the team can have many of them. Developers write most of them, but they belong in the strategy because many rules can be verified more cheaply and precisely here.
API tests—system behaviour. Creating an order, changing its state, permissions, the response to invalid input, or error handling. This level often offers a good value-to-cost ratio: the test generally runs faster than the same check through the user interface, and a redesign affects it less. Many combinations and edge cases can be verified more effectively here than in a browser. Read more in API tests.
UI tests—whether everything holds together. Use the interface mainly to verify representative journeys, not every combination. A customer signs in, finds a product, places an order, and pays; another scenario may cover registration or a key form. Adapt the number and depth of these tests to the risk and scope of the important user journeys.
This is why the model is a pyramid: more fast, isolated checks at the bottom and fewer complex end-to-end scenarios at the top.
Without dogma
The pyramid is a guide, not a law. Do not memorise exact ratios; the important rule is: verify at the lowest level where reliable verification is possible.
There are cases where this does not apply literally. If your application is primarily an interface over external systems and contains little logic of its own, it will naturally have few unit tests, and the emphasis will move to integration and API tests. If you deliver a product where appearance and layout are critical, visual comparison will take over some of the work. If you already have a large UI suite that works, there is no reason to discard it; the reason is not to add more combinations to it that belong at a lower level.
What the right distribution of tests gives you
A more appropriate distribution can shorten runs, reduce unstable results, and limit maintenance costs. Faster feedback also increases the chance that the team will use test results in its daily work.
When designing a strategy, we therefore first divide what should be verified at which level. If some combinations can move from the UI to the API or unit level, this can save substantial time in both runs and maintenance.
Next step
Send us what your tests currently cover and how long regression testing takes, then contact us. We will propose what to verify at a lower level, what to keep in the UI, and which risks currently lack proportionate coverage.