Speed up integration development with stubs
Recently my colleague and I had a task to develop integration with the third-party API. The task wasn't too hard except for one problem — the API was private, and getting access to it was a complex and lengthy process. Instead of waiting for permission to access API, we decided to mock the API endpoints required for the integration.
In this article, I'll share a technique to unblock the integration development process with limited access to the system that needs to be integrated.
Stubs for the rescue 🎉
A good stub is a dummy stub
A service that mimics the interface and simple behaviour of the third-party API (or simply stub) is a powerful tool. It is essential, though, not to overcomplicate things here. The stub should not have complex logic. A few logical branches are ok. But don't include any algorithms there. Also, avoid adding an extensive set of fixtures — a few canned responses are enough (happy paths and variations of error case scenarios).
A good stub is a small stub
Don’t mock the whole external API. Mock just the endpoints that need to be integrated.
A good stub runs everywhere
The stub should be runnable on the developer machine and the CI environment.
It should be easy to remove a stub
Remember, a stub is a temporary solution. It should be used for initial or local testing purposes only.
It is easy to switch from a stub to an actual service
As soon as access to the third-party service is granted, switching from the stub to the real service should be a matter of changing the service URL in the configuration.
To demonstrate a stub example, I created a faker service. The service was implemented in Deno. There are a few reasons why deno:
- It has native support of TypeScript
- It has a linter and formatter
- It compiles binaries for a specific platform
These features enable a rapid development process with a focus on the product.
Another powerful tool in the Deno ecosystem is Deno Deploy. It seamlessly integrates with GitHub and instantly deploys the Deno service worldwide. It enables more architecture options—to run a stub locally vs accessing a remote stub.
Faker is a template repository; please feel free to use it to create your stubs or maybe even actual services (don’t forget to add tests in this case).
Use stubs wise, test early, develop fast, and deliver quality software.
