Software Testing & QA

Build confidence in software through disciplined testing — from unit assertions to chaos engineering

Comprehensive documentation for software testing and quality assurance, from the fast unit tests at the base of the pyramid to the property-based, fuzz, and chaos techniques that find the bugs nothing else can. This hub frames the testing discipline as a whole and routes you into focused pages for the everyday practices and the advanced ones.

Overview

Testing is the engineering discipline of building justified confidence that software behaves as intended — and keeps doing so as it changes. It is not about proving the absence of bugs (which is generally impossible) but about systematically reducing the probability and blast radius of the bugs that remain. A good test suite is a safety net that lets a team refactor aggressively, ship continuously, and sleep at night.

What you’ll get: a working model of the testing pyramid and the trade-offs between test levels, the everyday craft of writing fast and trustworthy unit and integration tests, and the advanced techniques — property-based testing, fuzzing, mutation testing, and chaos engineering — that go beyond hand-written examples.

Assumed background: comfort with at least one programming language and version control. No prior testing experience required; we build from first principles and motivate each technique by the class of bug it catches.

The Testing Pyramid

The pyramid is the central heuristic for shaping a test suite. It sorts tests by scope and speed: the lower a layer, the smaller the unit under test, the faster and more deterministic the test, and the more of them you should have. The higher a layer, the more of the real system it exercises, the slower and flakier it gets, and the fewer you should keep.

flowchart TD
    E2E["End-to-End / UI<br/>few · slow · high-fidelity<br/>full system through real interfaces"]
    INT["Integration<br/>some · moderate speed<br/>modules, DBs, services talking to each other"]
    UNIT["Unit<br/>many · fast · isolated<br/>one function or class, no I/O"]
    UNIT --> INT --> E2E

The reasoning behind the shape is economic. A unit test failure points at a single function; an end-to-end failure could be anything from a CSS change to a database outage, so it costs far more to diagnose. Unit tests run in milliseconds and rarely flake; end-to-end tests run in seconds-to-minutes and flake on timing, network, and environment. You therefore want most of your coverage to come from the cheap, precise layer.

Level	Scope	Speed	Flakiness	How many
Unit	One function/class, dependencies stubbed	Milliseconds	Very low	Many (the broad base)
Integration	Several units, or a unit + real DB/queue/service	Tens of ms to seconds	Moderate	Some (the middle)
End-to-end	The whole system through its real interface	Seconds to minutes	High	Few (the thin top)

Two well-known anti-patterns invert this shape. The ice-cream cone piles most coverage into slow, brittle end-to-end tests with little unit coverage underneath — the suite becomes slow and unreliable. The testing hourglass has lots of unit and end-to-end tests but a starved integration layer, so wiring bugs between components slip through. The fix in both cases is to push coverage down to the cheapest level that can still catch the bug.

What “Good” Looks Like: the F.I.R.S.T. Properties

Independent of level, trustworthy tests share a set of properties often abbreviated F.I.R.S.T.:

Fast — fast enough to run constantly, so failures are caught the moment they’re introduced.
Independent — no test depends on another’s side effects or ordering; each sets up and tears down its own state.
Repeatable — the same result every run, in any environment, with no reliance on wall-clock time, network, or random seeds you don’t control.
Self-validating — a test passes or fails with a clear assertion, never requiring a human to eyeball output.
Timely — written alongside (or before, in TDD) the code, while the intended behavior is still fresh.

A test that violates these — slow, order-dependent, or flaky (non-deterministically passing and failing) — actively erodes confidence: teams learn to ignore it, and a red build stops meaning anything. Eliminating flakiness is therefore a first-class quality concern, not housekeeping.

Coverage Is a Floor, Not a Goal

Line and branch coverage tell you which code the suite executed, not whether it verified the right behavior. It is entirely possible to have 100% coverage with assertions that test nothing. Coverage is best used as a floor — “no new code below X%” — and as a map of untested regions, not as the metric you optimize. The techniques that actually measure test quality (does the suite detect injected faults?) live in mutation testing, covered in Advanced Testing.

Explore the Topics

The two areas below are ordered so that everyday craft comes before advanced techniques: master fast, trustworthy unit and integration tests first, then layer on the generative and resilience techniques that find what example-based tests cannot. Make tests drive design (practice TDD so tests shape interfaces, not just verify them); then move up to generative and system-level techniques — property-based testing and fuzzing for the inputs you’d never type, mutation testing to prove your assertions bite, and performance/load/chaos testing for behavior under the stress, partition, and failure that production eventually imposes.

Page	What it covers
Unit & Integration Testing	The testing pyramid in practice, test structure (Arrange-Act-Assert), test doubles, test-driven development, integration testing with real dependencies, fixtures, and managing flakiness
Advanced Testing	Property-based testing, fuzzing, mutation testing, snapshot and contract testing, performance/load testing, and chaos engineering

To see how these practices slot into an automated pipeline, see CI/CD Pipelines; for the failure-injection techniques specific to multi-node systems, see Testing & Chaos Engineering in the Distributed Systems hub.

Key Takeaways

Shape the suite like a pyramid. Many fast unit tests, fewer integration tests, a thin layer of end-to-end tests. Push every check to the cheapest level that can catch the bug.
Optimize for fast feedback. A suite that runs in seconds gets run constantly; a slow one gets skipped. Speed at the base is what makes testing a habit.
Make tests F.I.R.S.T. Fast, Independent, Repeatable, Self-validating, Timely. A flaky or order-dependent test is worse than no test — it teaches the team to ignore red.
Coverage is a floor. It tells you what ran, not what was verified. Use it to find untested code, not as the number you optimize.
Generate the inputs you can’t imagine. Property-based testing and fuzzing explore the input space example tests miss; mutation testing proves your assertions actually bite.
Test under failure, not just success. Performance, load, and chaos testing reveal the behavior that only emerges under stress, latency, and partition.