Most teams building against a partner's API hit the same wall: the spec is published, the real endpoint is not ready, and the work cannot start. Writing stub responses by hand is tedious, and existing code generators like swagger-codegen produce servers that return empty payloads—developers still have to fill everything in themselves. A small open-source Go tool called dummy takes a different approach: it reads the example values already embedded in an OpenAPI document and serves them as live responses the moment a route is called. No stubs, no manual wiring, just a contract turned into a running server.
What happened
- Dummy launches a mock HTTP server directly from an OpenAPI specification, returning the examples already defined in the spec.
- Installation requires one command: go install github.com/neotoolkit/dummy/cmd/dummy@latest.
- Run it with dummy s openapi.yml or dummy s <URL>—local files and remote URLs are both supported.
- A built-in faker handles dynamic data via custom fields like x-faker: firstname.
- Roadmap includes GraphQL, RAML, and gRPC support.
Background: the slow part of integration projects
In systems integration, the critical path is rarely the code. It is the negotiation over data shapes, the back-and-forth on field names, and the wait while a partner finishes its sprint. Swagger-codegen has existed for years, but it generates skeleton servers. A developer who calls a generated endpoint gets nothing back and has to write the response logic manually.
Dummy short-circuits that. By reading the examples already inside the OpenAPI document, the server returns realistic data the moment a route is hit. QA teams can point at it, run contract tests, and unblock parallel work without waiting on a real backend.
Our analysis
The interesting part is not the tool itself—it is the working pattern it represents: contract-first, mock-backed development. Teams that adopt this consistently ship faster because the dependency graph collapses. The risk is the usual one with mocks: the real API behaves differently, and the test surface was a lie. Treat the mock as a contract check, not as a final integration test, and keep a small set of end-to-end smoke tests against the real endpoint.
Compared with hosted mock services, a CLI tool like dummy has lower setup cost but no shared state for cross-team collaboration. If your integration involves more than two teams, you will outgrow a local mock quickly and want a hosted version. For two-team integrations and most QA cycles, the CLI is enough.
Who should care
| Role | Primary benefit |
|---|---|
| Golang developers | Test integrations without hitting a real partner API or writing stub handlers |
| QA specialists | Run contract tests against a documented contract without waiting for a backend |
| Tech leads and PMs | Unblock parallel workstreams; reduce surprise gaps when the real API finally arrives |
| API consumers evaluating vendors | Validate whether a vendor's spec is complete and consistent before committing |
What to watch next
Watch whether tools like dummy push the industry toward treating the spec as a buildable artifact rather than documentation. If they do, expect more vendors to ship richer example payloads, which raises the floor for everyone. Bottom line: small tools like this are how modern delivery teams remove the slowest dependency on the board.
Key takeaways
- Mocks built from the spec eliminate the "wait for the partner" bottleneck on integration projects.
- The tool serves QA and dev teams in parallel, not just one role.
- Treat mock-backed tests as contract checks; keep at least a thin layer of end-to-end tests against the real API.
- Evaluate whether a CLI mock is sufficient (small team, two-party integration) or whether you need a hosted solution (multiple teams sharing state).
Frequently asked questions
What is dummy?
It is an open-source Go tool that launches a mock HTTP server based on an OpenAPI specification, returning the examples already defined in the spec.
How is it different from swagger-codegen?
Swagger-codegen generates a server skeleton with empty responses. Dummy returns the examples from the spec, so you do not have to write them yourself.
Can I run it locally?
Yes. Install with go install github.com/neotoolkit/dummy/cmd/dummy@latest and run against either a local file or a URL pointing to an OpenAPI document.
Does it support anything other than OpenAPI?
Not yet. The roadmap includes GraphQL, RAML, and gRPC support.
When would a hosted mock be a better choice?
When more than two teams need to share state or run parallel test cycles against the same simulated API.