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

Test strategies have been explored throughout the years, with the common goal of finding the right amount of testing. The questions of why we test, what we test, and more importantly when we stop testing have puzzled test experts for years, resulting in almost philosophical conversations.

Testing has been divided into many groups and categories, the most famous of them being the test pyramid. This term is quite interesting, as its graphical representation is that of a two-dimensional triangle rather than a tridimensional pyramid, shown as follows:

Figure 2.1: 2D representation of a test pyramid

In the following three chapters, we will take a different approach to the test pyramid, trying to bring this third dimension into the picture. We will also be observing the test types that usually are forgotten in this schema and alert you to the hidden dangers on our virtual pyramid.

...

Technical requirements

A basic level of programming skills is recommended to get the best out of this chapter. The last section might require an intermediate level.

Developers might be especially interested in this chapter.

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, and we provide the examples so it is easier for you to play with them in GitHub: https://github.com/PacktPublishing/How-to-Test-a-Time-Machine/tree/main/Chapter02.

In this chapter, we will use Java with junit-jupiter:5.7.2, Python with unittest, and TypeScript code.

What is inside the base of the pyramid?

The base of the pyramid contains those tests that are closest to the development of the feature. Although there are some discrepancies around this claim, it is usually where most tests should take place. The reason is that the earlier the issues are found, the cheaper it is to fix them. In this case, the monetary value of finding an issue is measured by the amount of time spent figuring out why it has happened (debugging) plus the amount of time spent fixing it and the context switch needed if the developer has moved on to a different task.

Tests closest to the feature’s development are sometimes referred to as “structural.” In the 2D test pyramid (or triangle), the tests that are located here are unit tests.

Most developers include testing tools and processes in their development, although, interestingly, some of the tools and processes are not even considered as part of quality by them. Some developers claim that...

How to cheat on unit testing to achieve coverage and why you should not

Test coverage is a useful tool for making sure the unit tests are good enough. However, if they are used without being conscious of this fact, without good test knowledge, or without fully understanding why tests are needed in the first place, they will not be as useful as intended by their creators.

For example, imagine code for testing a calculator, as follows:

Calculator.java

package chapter2;
public class Calculator {
    public int add(int number1, int number2) {
        return number1 + number2;
    }
}

To make the coverage pass with 100% accuracy, we simply need to make sure we call the add method with any two numbers.

The following is an example of such code:

CalculatorTest.java

package chapter2;
import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;class CalculatorTest {
&...

Do not kill the mockingbird – how to level up your unit testing with mocking

The goal of unit testing is to make sure that a particular unit of code works on its own, but if you are using a library, it could be hard to force that library to return a specific value or values to ensure that the code developed using it works on its own. Let’s see that with an example. Imagine your code does not have access to the internet, and, therefore, the following piece will break if tested directly:

request_call.py

import requests
def invoke_get() -> bool:
       response = requests.get("https://www.packtpub.com")
       if response.status_code == 200:
          return True
     return False

Tip

Don’t panic about this code; we will explain requests and responses in the next chapter.

To test this unit, we...

Secret passage – automation at the base of the pyramid

As discussed in the last two sections, automation can be used to avoid repetitive code, both in unit testing and during mocking. In fact, mocking libraries are partially doing that very same thing. Furthermore, some integrated development environments (IDEs), such as IntelliJ IDEA, already have integrated plugins that can insert code automatically, and even create unit test classes. Visual Studio Code (VS Code) has several community-driven extensions that can automate these and other tasks that you are currently doing manually.

The first requirement to write automation over code is to be able to extract pieces of that code and give meaning to those pieces. This is usually done using an abstract syntax tree (AST) to represent this code:

• With Python, the ast library (see [1] in the Further reading section at the end of the chapter) provides the methods to create one
• In C#, they are referred to as “expression...

Summary

In this chapter, we learned what types of tools, techniques, and testing are used and performed at the base of the test pyramid. Developers so frequently use testing tools that they do not realize that they are even doing testing.

We reviewed the differences between coverage and good unit testing and how mocking can help when the code gets complicated and coupled.

Finally, we showed a way of automating the base of the pyramid to make these tests easier and more fun to write.

In the next chapter, we will look at the middle part of the test pyramid, and we will review backend testing, such as integration, APIs, and contact and shadow testing. This section of the pyramid can be managed by developers or test experts, depending on the company. For companies shifting left, it might be more common that developers are in charge of writing these tests, maybe overseen by a test expert. If you are a quality assurance (QA) tester or software development engineer in test (SDET...

Further reading

• [1] More about the AST library can be found here: https://docs.python.org/3/library/ast.html.
• [2] More about expression trees can be found here: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/expression-trees/.
• [3] A good example with Java can be found here: https://www.eclipse.org/articles/Article-JavaCodeManipulation_AST/.
• [4] Find out more about PSI at the following link: https://plugins.jetbrains.com/docs/intellij/psi.html.
• [5] See XUnit Test Patterns by Gerard Meszaros for a deeper dive into XUnit test patterns.