Test Architecture
Test architecture, types, and good practices for building confidence in your delivery pipeline.
Testing Fundamentals
Build a test architecture that gives your pipeline the confidence to deploy any change, even when dependencies outside your control are unavailable.
3 minute read
Phase 1 - Foundations | Scope: Team
Continuous delivery requires that trunk always be releasable, which means testing it automatically on every change. A collection of tests is not enough. You need a test architecture: different test types working together so the pipeline can confidently deploy any change, even when external systems are unavailable.
Testing Goals for CD
Your test suite must meet these goals before it can support continuous delivery.
| Goal | Target | How to Measure |
|---|---|---|
| Fast | CI gating tests < 10 minutes; full acceptance suite < 1 hour | CI gating suite duration; full acceptance suite duration |
| Deterministic | Same code always produces the same result | Flaky test count: 0 in the gating suite |
| Catches real bugs | Tests fail when behavior is wrong, not when implementation changes | Defect escape rate trending down |
| Independent of external systems | Pipeline can determine deployability without any dependency being available | External dependencies in gating tests: 0 |
| Test doubles stay current | Contract tests confirm test doubles match reality | All contract tests passing within last 24 hours |
| Coverage trends up | Every new change gets a test | Coverage percentage increasing over time |
In This Section
| Page | What You’ll Learn |
|---|---|
| Test Architecture | The principles behind a CD test suite: the pyramid, the trophy, and determinism |
| What to Test | Which boundaries matter and how to eliminate external dependencies from your pipeline |
| Pipeline Test Strategy | What tests run where in a CD pipeline and how contract tests validate test doubles |
| Getting Started | Audit your current suite, fix flaky tests, and decouple from external systems |
| Defect Feedback Loop | Trace defects to their origin and prevent entire categories of bugs |
| Test Types | Definitions of each test type and where it runs in the pipeline |
| Patterns | How to fully test eight common component patterns, from API providers to stateful services |
| Applied Testing Strategies | Cross-cutting concerns and a pre-ship checklist for any component |
| Test Feedback Speed | Why suite speed matters and the targets that follow from cognitive limits |
| Testing Antipatterns | Common testing antipatterns and how to get an existing suite back on track |
| Testing Glossary | Definitions for testing terms as this site uses them |
The Ice Cream Cone: What to Avoid
An inverted test distribution, with too many slow end-to-end tests and too few fast unit tests, is the most common testing barrier to CD.
The ice cream cone makes CD impossible. Manual testing gates block every release. End-to-end tests take hours, fail randomly, and depend on external systems being healthy. For the test architecture that replaces this, see Pipeline Test Strategy and the Testing reference.
Next Step
Automate your build process so that building, testing, and packaging happen with a single command. Continue to Build Automation.
Content contributed by Dojo Consortium, licensed under CC BY 4.0. Additional concepts drawn from Ham Vocke, The Practical Test Pyramid, and Toby Clemson, Testing Strategies in a Microservice Architecture.
Related Content
- Flaky Tests - Symptom of non-deterministic tests that destroy pipeline trust
- High Coverage, Ineffective Tests - Symptom where coverage metrics mask poor test quality
- Refactoring Breaks Tests - Symptom of white-box tests that assert on implementation details
- Slow Test Suites - Symptom caused by an inverted test pyramid or missing test doubles
- Environment-Dependent Failures - Symptom of tests coupled to external systems
- Inverted Test Pyramid - Anti-pattern where too many slow E2E tests replace fast unit tests
- Pressure to Skip Testing - Anti-pattern where testing is treated as optional under deadline pressure
What to Test - and What Not To
The principles that determine what belongs in your test suite and what does not - focusing on interfaces, isolating what you control, and applying the same pattern to frontend and backend.
Pipeline Test Strategy
What tests run where in a CD pipeline, how contract tests validate the test doubles used inside the pipeline, and why everything that blocks deployment must be deterministic.
Getting Started
Practical steps to audit your test suite, fix flaky tests, decouple from external dependencies, and adopt test-driven development.
Defect Feedback Loop
How to trace defects to their origin and make systemic changes that prevent entire categories of bugs from recurring.
Test Types
Definitions of the test types used throughout this site.
Patterns
Eight common component patterns and how to test each fully. Each page covers what to verify, positive and negative cases, double validation, pipeline placement, and a small code example.
Applied Testing Strategies
Practical guidance for fully testing eight common component patterns: API providers, API consumers, scheduled jobs, user interfaces, event consumers, event producers, CLI tools and libraries, and stateful services.
Test Feedback Speed
Why test suite speed matters for developer effectiveness and how cognitive limits set the targets.
Testing Antipatterns
Common testing antipatterns that block CD, plus a migration guide for getting an existing suite back on track.
Testing Glossary
Definitions for testing terms as they are used on this site.