Anyone who has done some test automation or has searched for information about the subject will have come across the famous “Testing Pyramid” more than once.

This figure represents the “ideal” way to distribute the automatic tests of a system in its different layers. Where the width, indicates the number of tests that should exist about the different levels.

Therefore, according to this distribution, it would be desirable that the number of unit tests is proportionally greater than the rest of the levels, and that as we go up the layer, these decrease.

The reason behind this recommendation is that unit tests are very fast to execute and “easy” to develop. In contrast, integration and e2e tests (typically through a web interface) are slower, more expensive to maintain, and require some additional infrastructure to run.

This diagram by Martin Fowler shows the relationship between all the variables:

This pattern became popular when tools like Selenium began to be used regularly since in many cases the test automation process was focused on trying to mimic the actions of users on a web page. Following this approach, in many situations, we arrive at an “inverted pyramid” or “ice cream cone” model, which is considered an anti-pattern, because it is not the most effective way to validate the quality of the systems in terms of cost-benefit.

At this point, we must understand that the “testing pyramid” is only a model that represents the “ideal” distribution of automated tests according to the layer on which they act. Therefore, it only refers to the number of them, but it does not indicate how to achieve this in terms of techniques, tools, frameworks, languages, roles, etc.

#performance #testing #service #test automation #qa #ui #unit #iceburg