00 - Summary
1. The four levels in detail
2. Integration strategies
3. Organizations to avoid
4. The testing pyramid
5. Key takeaway
01 - The four levels
What does each level do exactly?
01
Unit testing
Objective — Verify the behavior of an isolated component (function, class, module) independently of the rest of the system.
Who: Developers
When: With every commit
The lowest level of the pyramid. Fast, automated, and executed continuously, they form the basic safety net. They rely on *doubles* (mocks, stubs, fakes—test doubles used to replace real dependencies such as databases, APIs, or external services—in order to test a component in isolation) to isolate the code under test from its dependencies.
STRENGTHS:
-
Very fast (ms)
-
Precisely pinpoint defects
-
Document code intent
LIMITATIONS:
-
Do not validate interactions
-
May miss integration bugs
EXAMPLES:
-
JUnit, NUnit, pytest, Jest
-
Mocks, stubs
-
TDD:
-
Red: A small unit test describing the expected behavior of a function or method, where the code does not yet exist.
-
Green: The minimum amount of code required to make the test pass (without striving for perfection).
-
Refactor: Improve the code (better naming, removal of duplication, breaking down into functions, optimization).
-
Target coverage: 70–80% of critical lines.
02
Integration testing
Objective — Validate interactions between components or systems: API calls, database access, message queues, external services.
Who: Developers & QA
When: After Unit Testing, before System Testing
A distinction is made between component integration (between modules within the same application) and system integration (between applications or services). Classic strategies include: Big Bang, Top-Down, Bottom-Up, Sandwich, and Incremental.
STRENGTHS:
-
Validates actual exchanges between components
-
Detects interface issues
LIMITATIONS:
-
Slower and more costly than unit tests.
-
More complex to set up and maintain.
-
Diagnostics are sometimes less precise than with unit tests.
EXAMPLES:
-
Component integration
-
System integration (API ↔ Database)
-
Interface contracts
Target Coverage: Cover critical inter-component paths.
03
System testing
Objective — Evaluate the complete system against functional and non-functional requirements.
Who: QA
When: After a stable build, on a dedicated stable environment
Conducted as black-box tests within an environment representative of the production environment. They cover end-to-end flows, security, performance, cross-browser/cross-OS compatibility, and behavior under load.
STRENGTHS:
-
Holistic view of the product
-
Representative of the user experience
LIMITATIONS:
-
Slow and costly More fragile (flaky tests)
EXAMPLES:
-
End-to-end tests
-
Load tests
-
Security tests
Target coverage: Cover critical end-to-end scenarios.
Acceptance testing
Objective — Confirm that the system meets business needs and is acceptable to the user.
Who: Users / Business
When: Before going live
The ISTQB distinguishes several forms: UAT (User Acceptance Testing), contractual and regulatory testing, operational testing (OAT), alpha testing (conducted at the vendor's site), and beta testing (conducted by actual users).
STRENGTHS:
-
Validation by the actual user
-
Reduces the risk of rejection
LIMITATIONS:
-
Detects defects late in the process
-
Depends on the availability of business stakeholders
EXAMPLES:
-
Acceptance testing
-
Contractual testing
-
Operational testing
Target Coverage: Covering real-world usage scenarios and compliance with acceptance criteria.
02 - Integration strategieis
Integration strategies
How are components assembled and tested? The ISTQB identifies several approaches, each involving trade-offs between speed of implementation and ease of diagnosis.
Big bang
Everything is integrated all at once, then tested. Simple, but diagnosing the problem is difficult in the event of a failure.
We start with the high-level modules and work our way down, using stubs for the lower-level modules.
We start with the low-level modules—specifically the drivers—and then work our way up to the higher layers.
Sandwich
A combination of top-down and bottom-up approaches—we meet in the middle. A good compromise for large-scale systems.
Incremental
We integrate the components one by one, validating at each step. Diagnosis is easy, but takes longer.
03 - Patterns to avoid
The various testing organizations to avoid.
Ice cream cone
Lots of end-to-end tests, few unit tests. A slow, fragile, and expensive-to-maintain suite.
Hourglass
Lots of unit and end-to-end tests, almost no integration tests. Interface bugs are slipping through the cracks.
Cupcake (Test Hierarchy Anti-pattern)
Entirely manual, backed by a substantial base of unit tests. Not sustainable once the product grows.
04 - The idea pyramid
The testing pyramid
Theorized by Mike Cohn, it proposes a healthy distribution: many unit tests at the base, fewer integration tests in the middle, and few end-to-end tests at the top. The goal is not geometric perfection, but rather a balance between speed, cost, and confidence.
E2E / UI
Slow, fragile, and expensive—to be reserved for a few critical scenarios.
Integration / API
Validate contracts and interactions
Unit
Fast, numerous > foundation of trust
05 - Key takeaways
In short:
-
Each level has a distinct objective and owner—do not confuse them.
-
Unit tests provide rapid feedback; integration tests validate interactions; system tests cover complete user journeys; and acceptance tests confirm business value.
-
The test pyramid serves as a useful guide, but it must be adapted to the specific product and its associated risks.
-
A misplaced test (e.g., using an E2E test for something that could be a unit test) costs 10 to 100 times more. This effectively pushes bug detection toward the end of the project—a delay that amplifies the cost of fixing those bugs by the same orders of magnitude.
-
Who does what:
