The Secret Passages of the Test Pyramid – the Middle of the Pyramid

In the previous chapter, we explored the concept of the test pyramid and its base. If you skipped that chapter and decided to read this one directly, we recommend that you go over its introduction first to understand the test pyramid concept. In this chapter, we are going to cover the middle of the test pyramid and check all its dimensions, secret passages, and dangers.

In this chapter, we are going to cover the following main topics:

• What is inside the middle of the test pyramid?
• Differences between integration, API, and contract testing
• The secret passages – shadowing testing
• The other side of the middle of the pyramid – performance testing

Technical requirements

Some degree of programming skill is recommended to get the best out of this chapter.

Developers might be especially interested in this chapter, as well as quality experts (SDET/QA) who want to leverage their careers or currently work at this level of the pyramid.

This chapter uses examples written in various programming languages for everyone’s convenience. We recommend reviewing and working with different languages as a self-growth exercise. We have provided the examples so that it’s easier for you to play with them in our GitHub: https://github.com/PacktPublishing/How-to-Test-a-Time-Machine/tree/main/Chapter03.

What is inside the middle of the pyramid?

In the 2D models of the test pyramid, this section is generally reserved for “integration” testing, though it could also be used for service testing, system testing, contract testing, API testing, and so on. We can argue that a 3D test pyramid model is especially needed at this level, where many different test types are considered.

In this book, we are going to consider the middle of the test pyramid as the part that contains most of the backend-related testing of an application. I am also including performance testing as a hidden side of this level of the test pyramid.

As we build applications with different evolutions of the server-client architecture, we put more focus on the cloud. Careful testing becomes important here to make sure everything goes smoothly and to quickly and easily identify where exactly the problems are.

I remember once encountering a problem that was caused by a server in a bad state. This problem...

Understanding API, contract, and integration testing

To further clarify the difference between these tests and identify potential dangers and gaps when testing the middle of the pyramid, we have researched for many years and come up with the best schema that will express this:

Figure 3.1: The bicycle example

Yes! This is a bicycle.

The years of research part was a joke. However, one of the first questions that used to be asked in every interview that had anything to do with testing is “how would you test …” followed by a day-to-day item (generally a pen or similar). Let’s put that question to work here since a bicycle is a perfect visual example that could help us find the difference between these tests:

• The wheels are components. We can test that they have the right amount of air, friction, and so on (component testing).
• We can also test the unit of the code that would control the wheels – for example...

The secret passages – shadowing testing

Shadowing or mirroring testing is a type of test that is performed to verify two different versions of a system behave in the same way. This testing is especially useful when inheriting a system that already has little testing, to provide a quick check that everything is still in order.

It is done by recording the inputs of a system, as well as its outputs (careful here regarding what data is recorded, including how and who has access to this data), and then verifying them with the outputs in the new system. These replayed tests act like mirrors or shadows of the behavior of the old system over the new system.

Once the new system has been proven correct, we can switch off the servers to get the new code.

Shadow testing with an API

When an API is available and if the system allows it, it is better to make API calls to both production and pre-production environments with the same inputs so that the outputs are as close to each...

The other side of the middle of the pyramid – performance testing

Going back to our bicycle example, we could check how long it works without breaking or how much weight it can support. Performance testing could potentially be measured at any level of the pyramid, but the most common place is the middle.

The performance... of what?

When we talk about performance testing, most people think about the performance of the system in general, or maybe about each of the services or servers. However, there are many inputs we can check when we are checking performance, including the performance of the client’s browser.

Performance metrics

To understand the performance of our system, we should measure the performance of the different components and keep track of them.

For example, for web applications, we care that our servers are performing well and we can escalate introducing more servers on the go if we get more requests, but verifying the performance of the client...

Summary

With that, we have reviewed the faces of the middle part of the test pyramid. We started this chapter by defining the differences between the various backend tests and how they relate to each other. We explored API sending, schema validation, and message sending.

Then, we explored a secret passage, known as shadow testing, and when it would be more suitable to use it. Finally, we explored different types of performance testing.

In the next chapter, we will cover the top part of the test pyramid, as well as provide some tricks that you can use to increase the quality of your testing. We will do so by looking at some fun projects you can add to your portfolio.Both quality experts and developers might find the next chapter interesting.

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

1. Learn more about SOAP by reading this article: https://learn.microsoft.com/en-us/archive/msdn-magazine/2000/march/a-young-person-s-guide-to-the-simple-object-access-protocol-soap-increases-interoperability-across-platforms-and-languages.
2. REST dissertation from Roy Thomas Fielding: https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.
3. A nice history of SOAP and REST can be found here: https://thehistoryoftheweb.com/soap-rest-odds/.
4. A good article comparing SOAP and REST: https://www.redhat.com/en/topics/integration/whats-the-difference-between-soap-rest.
5. Testrail API documentation: https://www.gurock.com/testrail/docs/api.
6. JIRA information about rest-apis can be found at https://developer.atlassian.com/server/jira/platform/rest-apis/. Refer to https://developer.atlassian.com/server/jira for more information about JIRA.
7. The particular...