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.
Comments
Join the discussionNo comments yet. Be the first to comment.