There are many different types of software testing. They’re not interchangeable: each one caters to a different testing need and offers very different feedback. However, that doesn’t mean you should use every form of testing in the same proportion. There are smarter ways to go about it. One such way is what we call the test automation pyramid, which we’ll cover in this post.
What Is the Test Automation Pyramid?
The test automation pyramid, also known as the testing pyramid, is a concept that guides teams when it comes to prioritizing the different kinds of testing in a test strategy.
Mike Cohn introduced the concept of the testing pyramid in his 2009 book, Succeeding with Agile. The pyramid metaphor helps teams understand that, while different types of testing provide value in different ways, they also have different costs and pitfalls. All of those properties must be taken into account when deciding which types of tests to favor.
The Types of Testing in the Pyramid
Since the inception of the concept, it’s not rare to see the test automation pyramid represented in different ways or even featuring different forms of testing.
Traditionally, the pyramid features three types of software testing: unit tests, service tests, and UI tests.
The Base of the Pyramid: Unit Tests
The base of the testing pyramid features unit tests. That means you should have a larger quantity of unit tests than any other testing type. Why is that?
Unit tests are supposed to verify the behavior of a single unit—the smallest possible piece of software—in complete isolation. Because of that, unit tests are relatively easy to write, since they don’t require the setup of an involved environment or configuration. Since they don’t rely on external dependencies such as the database or the file system, they can only fail due to changes in the code—essentially, they’re deterministic. Also, they execute fast.
The Middle of the Pyramid: Service Tests
The next “floor” of the pyramid features service tests. Also called subcutaneous tests by Martin Fowler, these are tests that bypass an application’s UI and talk directly to the API underneath it.
Service tests are usually slower and offer less precise feedback than unit tests. They might also be harder to write since they’d typically require access to the external dependencies. Despite their complexities, they have the benefit of painting a more realistic picture, by verifying the app’s behavior in a way that’s closer to how the user interacts with it than unit tests.
The Top of the Pyramid: UI Tests
The top of the pyramid features what are called UI tests in Martin Fowler’s article, even though, in my definition, they’re more like end-to-end tests.
These are tests that drive the application the way a user would. These tests tend to be slow to run and very brittle since they might break due to the smallest change to the application’s UI. On the other hand, despite their problems, they do offer benefits. They mimic the way users interact with the application with much more realism than the other kinds of tests. Their results offer feedback that’s less precise. But at the same time, they might catch defects that the other types of testing would not.
To balance this, the testing pyramid says you should leverage this type of testing. Just make sure to have as few of them as you can get away with.
Consider the Test Automation Pyramid for Getting the Best Out of Your Testing Approach
Software testing is an essential activity. And what’s more, leveraging test automation is essential for tech organizations that want to deliver code as fast as possible while keeping quality high.
However, resources aren’t infinite. You have to use some strategy to decide how to allocate your resources when working on testing. The test automation pyramid is a metaphor that guides you on how to make those decisions.
If you’re interested in learning more about test automation in general, the Test Automation Boot Camp is something you might be interested in. Thanks for reading, and until next time.