22 Implementing a test pyramid strategy with JUnit 5

 

This chapter covers

  • Building unit tests for components in isolation
  • Building integration tests for units as a group
  • Building system tests for complete software
  • Building acceptance tests and making sure software is compliant with business requirements

The test pyramid is a way of thinking about how different kinds of automated tests should be used to create a balanced portfolio. Its essential point is that you should have many more low-level UnitTests than high-level BroadStackTests running through a GUI.

--Martin Fowler

As we have discovered in the previous chapters, software testing has several purposes. Tests make us interact with the application and understand how it works. Testing helps us deliver software that meets expectations. It is a metric of the quality of the code and protects us against the possibility of introducing regressions. Consequently, effectively and systematically organizing the process of software testing is very important.

22.1 Software testing levels

The different levels of software tests can be regarded as a pyramid, as shown in figure 22.1. In this chapter, we’ll discuss the following levels of software testing (from lowest to highest):

22.2 Unit testing: Basic components working in isolation

22.3 Integration testing: Units combined into a group

22.4 System testing: Looking at the complete software

22.4.1 Testing with a mock external dependency

22.4.2 Testing with a partially implemented external dependency

22.4.3 Testing with the fully implemented external dependency

22.5 Acceptance testing: Compliance with business requirements

Summary