Test scaffolding

Status: described, not built.

What it would do

Take acceptance criteria — Gherkin scenarios, an example map, a story’s criteria — and produce test skeletons in the repository’s conventions, at the level the strategy says each property belongs at.

Given:

Rule: gold members get 15% off orders over 100 euros
  Example: gold member, 120 euro order   → 102 euros
  Example: gold member, 80 euro order    → 80 euros
  Example: standard member, 120 euro order → 120 euros

It would produce a parameterised unit test in the project’s style — its runner, its assertion library, its builders — with the three cases as data, the names taken from the examples, and the expected values left as they were given.

Where its boundary is

It does not invent assertions. The expected values come from the examples. If a case has no stated expectation, the skeleton carries a failing placeholder rather than a guess — a guess would be derived from reading the implementation, which produces a test that agrees with whatever the code already does.

That is the whole distinction from “AI writes your tests”, and it is why the tooling section rules the latter out while this is worth describing.

It does not decide the level. It proposes one, from the strategy’s rules — a pure calculation is a unit test, anything touching persistence is integration, a journey is end-to-end — and the proposal is visible and overridable. Levels are a strategy decision; getting them wrong quietly is how a suite drifts into an ice-cream cone.

It does not fill in the arrange block beyond what the criteria state. A test whose setup contains six fields nobody asked for teaches the reader that all six matter. See writing a test.

It does not touch existing tests. Additive only. A tool that rewrites a suite is a tool nobody can review the output of.

What it would need to read

• The acceptance criteria — the input.
• The repository, for conventions: runner, assertion library, builders, naming style, directory layout. A skeleton in a foreign style is rejected on sight.
• The strategy table, for level selection.
• The existing suite, to detect that a property is already covered elsewhere — the rule against paying twice is the easiest one for a generator to break, and it would break it at volume.

That last item is the most valuable and the hardest.

Why it might not be worth building

A skeleton is not the expensive part. The cost of a test is deciding what to assert and getting the setup honest. If a generator saves the boilerplate and leaves the thinking, the saving may be twenty minutes a story.

Convention detection is brittle. Getting the style subtly wrong produces output that is more annoying to fix than to write.

It can encourage volume. A tool that makes tests cheap to produce, in a discipline whose main failure is having too many of the wrong tests, is not obviously a net good. See suite shapes.

The strongest argument for it is not speed. It is that generating from acceptance criteria makes the criteria load-bearing — a story with vague criteria produces a visibly useless skeleton, which is feedback arriving at the moment it is cheapest to act on. That is shift-left with a tool attached, and it is the version worth building if any is.