Martin Fowler first proposed the concept of the test automation pyramid[1] in 2012. It’s a technique to think about how you should use different types of test automation to get the maximum value out of them.
The main idea behind the test pyramid is to have many unit tests and a few broad tests for the GUI.
GUI testing is very brittle. User interfaces are constantly changing. An enhancement to the software easily breaks up many tests, which need to be updated, causing additional work for the team. Testing the UI is slow and results in increased build times. You can perform it on a few machines on which you have the license for the GUI testing tool.
Hence, the test pyramid argues that you should have more automated unit tests than through the traditional UI-automation tests. It also has an intermediate layer of service tests that can provide many benefits of end-to-end UI tests without the complexities of dealing with the UI frameworks.
