Modern Test Pyramid - Illustrated

System Level Tests, Component Level Tests, Unit Level Tests

Apr 25, 2025

∙ Paid

📢 My next Live Q&A Session about Unit Tests is on Wed 30th April 17:00. If you’re an Optivem Journal paid member, get your 100% discount ticket.

Upgrade to join the Live Q&A for free:

Previously, we introduced the Modern Test Pyramid:

Let’s break it down, firstly we have the System Test Pyramid, whereby we test the whole System, as a black-box:

The System is composed of Component(s), for example:

Monolith:
- Component #1: MVC App
Frontend & Backend:
- Component #1: Frontend
- Component #2: Monolithic Backend
Frontend & Microservices:
- Component #1: Frontend
- Component #2: Order Microservice
- Component #3: Product Microservice
- Component #4: Payment Microservice

For each Component, we make a decision whether to adopt:

Component Test Pyramid I; or
Component Test Pyramid II

If the Component has relatively low business complexity, then it can make sense to just adopt the following:

However, if the Component has higher business complexity, then the following would be more helpful in providing us with faster feedback:

Putting it all together, we have the single System Test Pyramid and we have Component Test Pyramid(s) which differ on per-Component basis:

System Level

System Architecture

The User (e.g. Customer) uses our System (e.g. eShop) to satisfy some goals (e.g. buy products online). Our System (eShop) connects to External Systems (PayPal, SAP ERP, Clock).

Note: Here we’re showing only one External System, but there could be multiple External Systems.

Smoke Test

A Smoke Test checks whether the System is up-and-running (e.g. does the eShop home page and other pages load).

E2E Test

In the Production Environment, the End User uses the real System, connected to Production Instances of the External Systems.

An E2E Test is the same, except it runs in the UAT Environment (not Production) and our System is connected to Test Instances of External Systems.

Acceptance Test

An Acceptance Test is like an E2E Test, except we stub out the External Systems (rather than using External System Test Instances). We do this so that we can simulate any scenario, thus we can test out any Acceptance Criteria.

External System Contract Test

Since the Acceptance Tests rely on External System Stubs, we need to be sure that the stubs match the real External Systems.

Component Level

Component Architecture

Let’s zoom into the System. We can see that the System is composed of one or more Components.

E.g. the System could be composed of Frontend & Monolithic Backend, or Frontend & Microservice Backend, etc.

Component Tests

In order to test each Component in isolation, we need to stub out any dependencies (External Systems & other Components).

The following is an example, whereby we:

Test Frontend in isolation - we target the UI components, and we mock out the Backend.
Test each Microservice in isolation - we target the Microservice via its API (e.g. REST API, SOAP Service, RabbitMQ consumer) and we stub out dependencies (other Microservices & External Systems)

Note: We can use Dockerized instances of the database and message broker. Thus, we have the most realistic Component Tests.

Optivem Journal