Spec-First vs Code-First Stubbing
Short answer: Code-first stubbing starts from the test and is immediately expressive; spec-first starts from the contract and is correct by construction. The first is a discipline of maintaining stubs; the second is a discipline of maintaining the spec. For a team that already versions an API, the spec is the durable source.
What code-first optimizes for
Immediacy and control: write the stub in the test, match exactly, and run. The cost is that the stubs are a separate description that can drift.
What spec-first optimizes for
| Property | Code-first | Spec-first |
|---|---|---|
| Source | Stub code | Contract |
| Upfront cost | Low | Modeling |
| Drift | Common | Rare |
| Generated surfaces | None | Many |
Why the spec scales
One contract drives the mock, the docs, and the tools, so a change is made once. Code-first stubs are updated in the tests and nowhere else.
The honest tradeoff
Code-first is the pragmatic start for a JVM test. Spec-first pays back as the surface grows and the languages multiply.
This is part of the Powerduck vs WireMock comparison. Next, read the cloud comparison.