In recent my posts, I talk about the AAA model of the testing and what is the importance of testing. Now I think this time is perfect for introduce and talk about the testing Pyramid.
The concept of the testing pyramid is introduced by Mike Cohn in 2004. Then in 2009 The formal and polished version of the testing pyramid is introduced in his book “Succeeding with Agile”. They introduce three levels pyramid which is UI tests, Service tests and Unit tests.
The levels of pyramid divides based on their scope, speed, cost and frequency. Different levels have different scope, speed, cost and the running frequency. Based on this parameter, you can easily decide which type of tests to use, where to use them, and how much of each type you need.
Generally, the ratio of this tests levels is 10:20:70. 10 percent of your tests is UI tests, 20 percent tests is service tests and rest of 70 percent tests is unit tests. This ratio is popularized by the google in 2015, in their testing blog “Just Say No to More End-to-End Tests”.
Now let’s understand deeply what are those different levels. Let’s start with unit tests.
Unit Tests
Generally, Unit tests are small and independent block of tests for small feature, small function or small component. This unit tests are isolated then other tests. It tests and checks smallest part of the program.
It run on isolation so that their scope is limited to that function or that component. Unit tests are extremely fast due to mocking of database query, API requests and file I/O. The mocking of those operation makes unit tests faster to execute.
The frequency of the unit tests is very high. After every file change, the unit tests run automatically, testing the relevant cases and providing instant feedback.
Now after every change the test cases automatically checks every component or feature then if any mistake was created it directly indicates failure and the cost of fix this mistake in development phase is very cheap.
So that’s is all about unit tests now let’s understand service tests.
Service Tests
In unit tests we tests individual component, function or feature working individually in isolation or not. But that is not necessary if component works on isolation then it also works when they dependent to each other. In real application most of function is dependent on some component or some dependency in this time unit test is not reliable. So, we done service tests.
In service case we test that the interaction between different parts like function or component is done reliably or not. The goal is to ensure that the complete system behaves correctly when its components are connected.
In service tests, mocking is rarely used. In case where you use external API that is expensive, unreliable or unavailable then the mocking is used in service tests.
In service tests the scope of the tests is from two component to multiple component due to use case of service test. The component is not isolated because they depend on other component so the speed of executing service test is slower than unit test.
The frequency of service tests is lower than unit tests. Because service tests require multiple components or dependencies to work together, they take more time to execute. So we don't need to run every service test after every small file change.
But when we change something that can affect the interaction between components, service tests become very important.
They give us confidence that different parts of our application are working correctly when they are connected with each other.
Now we understand unit tests and service tests. But there is still one level remaining in the Testing Pyramid. That is UI tests.
UI Tests
UI tests are tests where we test the application from the user interface. Instead of directly testing a function or connecting different components, here we test the application from the point where the real user interacts with it.
The test can open the application, find the email input, enter the email, enter the password, click on the login button and check whether the user successfully reaches the dashboard.
So, UI tests test the complete user interaction with the application.
The scope of UI tests is much bigger than unit tests and service tests because it can cover the complete application flow. It can involve UI components, frontend logic, backend services, database and other dependencies.
Because of this large scope, UI tests are much slower than unit tests and service tests. The test needs to start and interact with the application and sometimes it also needs to communicate with the backend and database.
The cost of UI tests is also higher. Writing and maintaining these tests takes more time because even a small change in UI can break the test. For example, if we change the button structure or change some text or element, the UI test may need to be updated.
The frequency of UI tests is also lower. We don't want to run every UI test after every small change because they take more time and resources.
So if we compare all three levels, unit tests have the smallest scope, highest speed, lowest cost and highest frequency.
Service tests have a bigger scope than unit tests, slower speed, higher cost and lower frequency.
UI tests have the biggest scope, lowest speed, highest cost and lowest frequency.
This is the basic idea behind the Testing Pyramid.
There is one more thing that is important to understand.
The terminology around the Testing Pyramid has changed over time.
The original Testing Pyramid described the three levels as Unit Tests, Service Tests and UI Tests.
But as software development practices evolved, different teams and organizations started using different terminology for these levels.
The term UI tests is now often discussed as End-to-End tests, or E2E tests, and service tests discussed as integration tests.
Top comments (0)