Dummy open-source: one command to test your API before it’s even built
Read an article about dummy, an open-source golang analogue of prism by stoplight for API mocking, testing and running the server locally.
When our Golang developer, Alexander Melentyev, was working on one of our client’s projects, he had to work on integrations with the partner's API. During the integration, we didn’t want to pull the real API, so there was a need use mock data to test API. The partner had an openAPI specification, on the basis of which it was possible to generate a server using swagger-codegen, but such tools have a nuance—they generate stubs, meaning that if you follow the "handle" from the specification, you will get an empty response, and you will need to write it yourself. Usually, this is time-consuming, and in this case, we didn’t have the necessary time. So the idea came up to launch a server based on the specification, which would give examples described in the specification when going through the "handle".
We started looking for tools that would do something similar. We found a prism open-source solution written in NodeJS and wanted to implement a similar idea in Go. So, we talked with QA specialists and found that a tool such as a Golang mock server for testing would also be useful for them, so that they would not have to write everything by hand. With its help, QA specialists could simply take a specification from a partner and just run everything with a single command—saving a lot of time and resources.
So Alexander created dummy, a very useful and in-demand tool that can help launch a mock server based on an API contract, which helps people see how the API will work before it's even built. You can run it locally with the
dummy server command to run your API on an HTTP server that you can interact with.
How to use dummy?
Using dummy is easy: you just need to install it, then you need to use the server command and pass the path to the specification into it. Both links and file paths are supported. It is useful when you need to integrate with a real API, without creating an extra load. Also, the tool is suitable for testing, so you don’t have to write a mock API—you can just use dummy.
go install github.com/neotoolkit/dummy/cmd/dummy@latest
Run it locally with the
dummy s command to run your API on a HTTP server you can interact with.
dummy s openapi.yml
dummy s https://raw.githubusercontent.com/neotoolkit/dummy/main/examples/docker/openapi.yml
If there is a need for dynamic data during integration, you can use the built-in faker. In the specification for the fields, you need to add a custom field
x-faker and pass the required data type to it. For example, if you need to dynamically generate a name, you need to set the following:
You might be wondering, why not use generators like swagger-codegen? It’s because swagger-codegen generates a server, meaning that you need to make several actions instead of one. The server will be generated, and you will be able to go to the addresses that are described in the documentation, but the response will be empty. In fact, you will not receive any integration, because there will be no data in the response. And in dummy, if any examples are described in the specification, then they will come in the response.
Plans for the future
Currently, only OpenAPI is supported, but plans for the future include adding support for GraphQL, RAML and gRPC. Our work on open-source projects—and the fact that every month we choose several OSS projects to sponsor—shows our initiative and understanding of what developers love and need. Reach out to us via the form below if you need to develop an open-source solution or are looking for a team of professionals to build a project from scratch!