## Definition **Key examples** are the minimal, carefully selected set of concrete cases that together fully characterise a business rule — as opposed to an exhaustive enumeration of every possible input. Gojko Adzic's core discipline in [[Specification by Example - Gojko Adzic]] is that a specification gains nothing from adding a fourth example that illustrates the same boundary already covered by the first three. ## The three categories of key examples Adzic identifies three roles that populate the key examples for a given feature: | Category | Who proposes | What it covers | |---|---|---| | Happy-path representative | Business analyst / product owner | Each important aspect of business functionality | | Technical edge case | Developer | Boundary conditions and functional gaps that code may expose | | Troublesome area | Tester | Cases that caused bugs in the past; boundaries not caught by the above | All three categories are present in a well-formed specification. If only the first exists, the spec is naive. If only the last two dominate, it has become a regression suite rather than a specification. ## Why exhaustiveness is the wrong target Exhaustive example sets have two compounding costs. First, the specification becomes too long to read: the key intent is buried. Adzic quotes a developer reaction to a compliance spec that over-enumerated every permutation: "They looked at the tests and were confused; they couldn't see the forest for the trees. They could not use the tests because they did not know what to code." Second, executing hundreds of near-identical examples delays feedback with no increase in confidence. The alternative is to list only key examples in the main specification and, if exhaustive exploration is needed, create a supplementary automated test linked from the specification. The primary specification provides quick feedback; the supplementary test runs overnight. ## Distinguishing a key example from a script A key example describes *what* the system must do, not *how* someone would test it. A workflow step-by-step (log in → navigate → click → verify) is a script; it may be precise but tells no one which business rule is at stake. A key example isolates a single action and its pre- and post-conditions. The shift from "how to test" to "what the system does" is the core of [[Gherkin Scenario]] structure. ## Relationship to key examples in SDD In [[Spec-Driven Development]] the key examples serve double duty: they are the acceptance criteria an agent receives as its definition of done, and they are the verifier suite that the agent's output must satisfy. Over-specified examples make agent tasks ambiguous by drowning the signal in noise; under-specified ones leave gaps an agent will fill with assumptions. ## Related - [[Specification by Example]] - [[Gherkin Scenario]] - [[Executable Acceptance Criterion]] - [[Three Amigos]] - [[Spec-Driven Development]] ## Sources - [[Specification by Example - Gojko Adzic]]