The software testing trophy is a lesser-known alternative to the popular testing pyramid. This post dives into the details of the testing trophy and its differences to the testing pyramid.
As we know, testing is non-negotiable in software development: either you make time for it, or you’ll need to deal with the consequences later. Testing is carried out at all stages of software development, with testing at each of these stages having a different focus.
There are various testing models to describe how this focus changes, and how to go about testing in an efficient way. We’ve already analyzed the most popular one, the testing pyramid, in an earlier post on the Symflower blog.
Let’s see what the test trophy model is and how it relates to the testing pyramid!
The different shapes of testing: pyramid vs trophy
Testing is generally “cheaper” closer to the base layer. Tests that focus on smaller components are easier to write and faster to run, which is what makes unit testing an efficient way to test code. As we introduce more components and take a broader focus, testing becomes more costly (e.g. more complex tests are difficult to build and take longer to run).
Generally, there is a trade-off between speed and confidence, so you can’t really skip any level of testing – but you can decide how much focus you place on the different levels of testing. Essentially, it’s about finding the right balance between your time investment and optimal return in terms of confidence in your software application. That’s what the different shapes of testing signify.
Martin Fowler and Kent C. Dodds describe two models or shapes of testing: the testing pyramid and the testing trophy.
What is the testing pyramid?
The testing pyramid defines three different levels of testing: unit, integration, and system tests. These build on top of each other as the number of components (and the complexity of tests) increase:
- Unit testing: Used to verify that the smallest building blocks of software, tested in isolation, work as expected (e.g. individual functions and methods).
- Integration testing: Analyzes the combination of two or more components to verify that their interactions behave as expected. (Check out our blog post to learn more about unit testing vs integration testing!)
- System testing: Takes into account all the components of the system, used to test the complete product.
The testing pyramid has unit tests at the bottom, meaning that those following the testing pyramid will carry out a lot of unit tests (or focus their efforts primarily on unit testing), assign somewhat less focus to integration tests, and carry out the necessary system tests only to limit the effort that goes into writing and running complex tests. The point is, of course, to use “cheap” tests to catch problems with minimal effort as early as possible.
As you may know from experience, unit tests are actually far from being “cheap” since you have to plan and write them all manually. It can take considerable time to create a comprehensive unit test suite. Using a unit test generation tool like Symflower that takes care of boilerplate code and can even generate full unit tests is a good idea to save a lot of time and effort.
What is the testing trophy?
When compared to the pyramid, the testing trophy introduces static testing as the foundation of all testing activities. This level covers the use of static tools like linters to catch problems like typos and syntactical errors.
The testing trophy approach assigns the most importance to integration testing. The reasoning is that you generally need fewer integration tests to identify problems in the application, and they are not as dependent on the details of the implementation – yet can be written and run relatively fast. Also, unit tests need to be maintained and adapted as the implementation changes. Integration tests, however, require less effort as development evolves.
Testing trophy vs testing pyramid?
How you end up distributing your testing efforts (e.g. whether you apply a testing pyramid or a testing trophy approach) depends on the individual project, the programming language applied, and a range of other factors.
While it is important to have a good unit testing base, both the testing pyramid and testing trophy empathize that a solid level of integration testing should not be overlooked. A good example are integration tests for application frameworks, such as testing Spring Boot controllers. Of course, a good integration test generation tool like Symflower will save you massive amount of time, as integration tests have far more setup code than regular unit tests. However, what your eventual testing “shape” will look like depends to a great extent on the type of application you’re developing.
It’s also important to remember what Kent C. Dodds emphasizes in his blog post: the concept of the testing trophy applies to the development of an individual codebase, with serverless functions, microservices, and other concepts not considered. Factoring in all these extra considerations may affect whether your testing resembles more of a trophy or a pyramid.
Make sure you never miss any of our upcoming content by signing up for our newsletter and by following us on Twitter, LinkedIn or Facebook!