Generate test doubles from the API description
Test stand-ins written by hand, replaced with ones generated from the specification so they cannot fall behind.
The ticket
Replace hand-written stubs with doubles generated from the API specification.
Acceptance criteria
- Doubles are generated by a committed command rather than edited by hand
- Regenerating produces no diff when the specification is unchanged
- Every hand-written stub it replaces is deleted
- The generation step runs in the pipeline
What lands as proof
A regeneration that produces an empty diff, which is what proves the doubles and the specification agree.
Why teams defer it
- Generation needs a trustworthy specification, and if the specification is not trustworthy this becomes two projects.
- Hand-written stubs are easier to read, so there is a real argument for keeping them that has to be answered.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: replace hand-written stubs with doubles generated from the API specification. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means doubles regenerate from the specification, so drift stops being possible, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.