An example test pairs a hand-picked input with an assertion about what the code does with it. The assertion is usually an exact expected value, but equally a property the output must satisfy, a round-trip relation, or merely that nothing crashed. It is the foundational verification technique in most codebases: the everyday categories of automated test are all example tests, separated only by how much of the system a run exercises and the resources it is allowed.

Example tests are the right tool when the relevant cases are small in number, enumerable, and known to the author. Past that range the author cannot write the cases out, and property-based testing or fuzzing generates them instead.

What it catches

• Regressions of fixed bugs. Once an example test captures the input that caused the bug, the same case cannot reach production silently again.
• Golden-path correctness. The common, expected use of the feature works as specified.
• Specified edge cases. The empty list, the zero amount and the max capacity behave as the author wrote them down.
• Behavior the spec enumerates. A finite set of declared cases (state transitions, status codes, mode toggles) maps naturally to a finite set of example tests, one per case.
• Documented examples. Test as documentation: the test is the worked example a future reader needs.

What example tests structurally cannot catch

Example tests guarantee the absence of known bugs, not the absence of bugs. A regression test needs no more than that: the bug it pins is already known.

Tools

Every mainstream language has stable example-test infrastructure. The runners named for each language are common defaults, not a complete set.

• JavaScript / TypeScript — Vitest (modern default), Jest, node:test (stdlib, stable since Node 20), Mocha.
• Python — pytest (the de facto default), unittest (stdlib).
• Rust — cargo test (stdlib #[test]), nextest for speed and richer reporting.
• Go — go test (stdlib).
• Java / Kotlin — JUnit 5, TestNG, Spock (Groovy).
• Ruby — RSpec, Minitest.
• C / C++ — GoogleTest, Catch2, doctest.
• C# — xUnit.net, NUnit, MSTest.
• PHP — PHPUnit, Pest.
• Elixir — ExUnit (stdlib).

Most of these support fixtures, parameterized tests (one example body × multiple input rows) and parallel execution. Vitest, Jest and node:test also ship snapshot/approval captures.

When to use, when not

Use example tests:

• For every bug fix — pin the case as a regression.
• For specified, finite behavior — a state machine with a handful of transitions; a function with three error codes.
• As golden-path system tests — one happy-path scenario per high-value flow, exercised through the assembled system.
• For smoke checks at a deploy boundary — fast, heuristic-tier, deliberately limited.
• As documentation. A failing test is a precise bug report; a passing test is an executable example.
• When other methods would be overkill. A configuration loader with three valid shapes and two error cases doesn't need a property-based test; five example tests, one per case, cover it.

Don't lean only on example tests when:

• The input space is rich and irregular — parsers, encoders, numerical code, ML, anything that takes "data with structure". Example tests still belong in the suite for the cases that specifically matter, beside property-based testing, fuzzing, metamorphic testing or differential testing, but they no longer supply the primary input.
• The code is concurrent or distributed. State-space explosion makes hand-enumeration insufficient; see deterministic simulation testing and model checking.
• The boundary is security-sensitive. An attacker, not the author, picks the inputs there, so hand-picked cases miss the ones that matter; fuzzing, threat modeling and static analysis belong beside them.
• AI generated the code. Its characteristic defect compiles and reads as correct but does the wrong thing, the kind that hides between AI-generated code and AI-generated example tests written from the same intuition. The other methods don't share that intuition.

Evidence

Example tests are the baseline other methods are measured against, not a treatment measured against a control, so the case for them is definitional rather than empirical. A suite of N example tests establishes only that the code behaves correctly on those N inputs.

Classification

• Quality dimensions: Functionality, Maintainability (as a regression / snapshot refactor-safety net).
• Area: Regression prevention, golden-path coverage, bug-fix verification, fast-feedback during development; any code with small, enumerable behavior the author can pin down by hand.
• Guarantee: Empirical — the cases tried passed.

Referenced by

• Functionality · Quality dimensions
• Quality dimensions · Quality dimensions
• Effect scope · The axes
• Guarantee · The axes
• Oracle · The axes
• Code review · Methods
• Combinatorial and pairwise testing · Methods
• Microbenchmarking · Methods
• Profiling · Methods
• Property-based testing · Methods
• Snapshot and approval testing · Methods
• Statistical and sampling testing · Methods
• Temporal-logic falsification · Methods
• Testing GUI and mobile applications · Methods
• Playwright · Recipes
• How AI fits into software quality · AI
• Glossary · Overview