Layered Testing Strategies: Knowing What You Already Did

Testing strategies are often visualized as a “pyramid” to represent the distribution of different types of tests. While the “Standard Pyramid” is the most famous, different architectural needs have birthed the “Top-Down,” “Bottom-Up,” and “Hourglass” models.

Each represents a different philosophy on where to invest your most expensive resource: Time.

1. Top-Down Testing

In this approach, testing starts with the highest-level modules (the UI or the main control flow) and works its way down to the individual units.

How it works: You use “Stubs” to simulate the lower-level modules that aren’t built or integrated yet.

Pros:

• High Visibility: Stakeholders see a “working” (albeit hollow) product early.
• Interface Validation: You catch major architectural flaws in how the system’s main components interact early on.

Cons:

• Stub Overhead: Writing and maintaining complex stubs for every low-level function is a massive time sink.
• Late Logic Catch: Critical bugs in the deep “engine” of the app might not be found until the very end.

2. Bottom-Up Testing

This is the inverse: you start by testing the smallest, lowest-level units (drivers, utility functions, database helpers) and gradually integrate them into larger subsystems.

How it works: You use “Drivers” to simulate the higher-level calls that would normally trigger these units.

Pros:

• Early Robustness: By the time you reach the UI, the foundation is rock-solid.
• Easy Debugging: If a test fails at this level, you know exactly which function is broken.

Cons:

• Invisible Progress: You might have 100% passing tests but still no “app” to show the client.
• Interface Risk: You might find that your perfectly tested units don’t actually fit together at the top level (the “Two-Unit-Tests-Zero-Integration-Tests” problem).

3. The Hourglass (The Anti-Pattern)

The Hourglass occurs when a team has many Unit tests and many End-to-End (E2E) UI tests, but almost zero Integration tests in the middle.

How it works: The “waist” of the pyramid disappears. You trust the units and you trust the final UI flow, but you don’t test the API or service layer where they meet.

Pros:

• Fast Unit Tests: Developers get quick feedback on local code.
• User-Centric: E2E tests ensure the “Happy Path” works for the customer.

Cons:

• Slow and Brittle: UI tests are notoriously flaky and slow to run. If the middle layer is missing, the E2E tests have to do too much “heavy lifting.”
• The “Gap” Problem: If an API change breaks a contract but doesn’t immediately crash the UI, you might not catch the bug until it hits production.

Comparison Summary

Style	Primary Focus	Main Tool	Risk Level
Top-Down	User Experience	Stubs	High (Core logic bugs found late)
Bottom-Up	Code Quality	Drivers	Medium (Integration bugs found late)
Hourglass	Extremes (UI & Unit)	Scripts	High (Missing the "Integration" bridge)

Which should you choose?

Most modern DevOps teams strive for the Standard Testing Pyramid, which favors a thick middle layer of Integration/API tests. This avoids the brittleness of the Hourglass while ensuring the components actually talk to each other correctly.