Short answer: A JVM mock is a single-language target; a spec mock is generated from the contract and serves every client. For a polyglot team, the shared contract is the only way to keep the Node, Python, Go, and Java clients aligned to the same API.
What a single-language mock provides
Maximum control for the JVM tests and no target for the other clients. The non-JVM clients either hit a live server or maintain their own mocks.
What a shared spec mock provides
| Property | JVM mock | Spec mock |
|---|---|---|
| Clients served | JVM | All |
| Source | Stub code | Contract |
| Alignment | One client | Every client |
| Maintenance | Per language | One spec |
Why the shared target matters
When every client develops against the same mock, a contract change is reflected once and the clients cannot drift apart. Separate mocks multiply the maintenance.
The decision rule
Use a JVM mock for a JVM-only codebase. Use a spec mock when the team spans languages.
This is part of the Powerduck vs WireMock comparison. Finish with faults and delays.
Comments
Join the discussionNo comments yet. Be the first to comment.