3 JUnit architecture

Architecture is the stuff that’s hard to change later. And there should be as little of that stuff as possible.

--Martin Fowler

So far, we have broadly surveyed JUnit and its capabilities (chapter 1). We’ve also looked at JUnit core classes and methods and how they interact with each other, as well as how to use the many features of JUnit 5 (chapter 2).

This chapter looks at the architecture of the two most recent JUnit versions. It discusses the architecture of JUnit 4 to show where JUnit 5 started, where the big changes are between versions, and which shortcomings had to be addressed.

3.1 The concept and importance of software architecture

Software architecture refers to the fundamental structures of a software system. Such a system must be created in an organized manner. A software system structure comprises software elements, relationships among those elements, and properties of both elements and relationships.

Software architecture is like the architecture of a building. The architecture of a software system characterizes the foundation on which everything else sits, represented by the bottom boxes in figure 3.1. Foundational software architectural elements are as hard to move around and replace as are the foundational parts of physical architecture, because you have to move all the things on top to reach them.

3.1.1 Story 1: The telephone directories

3.1.2 Story 2: The sneakers manufacturer

3.2 The JUnit 4 architecture

3.2.1 JUnit 4 modularity

3.2.2 JUnit 4 runners

3.2.3 JUnit 4 rules

3.2.4 Shortcomings of the JUnit 4 architecture

3.3 The JUnit 5 architecture

3.3.1 JUnit 5 modularity

3.3.2 JUnit Platform

3.3.3 JUnit Jupiter

Summary