Why we are mocking the world’s APIs
With so many different tools in the mocking world, why bother creating a new one?
We’re building DevOps tools 2.0, and our first product — unmock (we like to avoid caps-locking it)— took a few twists and turns before coming into fruition. We like to think of it as “The Internet. Mocked.” But there are many competitors in the mocking world; from language specific to method-specific, they all offer various tools and instruments for mocking your favorite APIs. How is unmock special? How is it different and why do we even work on a new tool in such a proliferated niche world?
First, why do people even mock, to begin with? In a test-driven development (TDD) environment, mocking is a common way to handle 3rd party dependencies. It has all kinds of benefits, but you can read about it more in depth here and here, for example.
When gearing up and mocking things, there are many common pitfalls that are quite often overlooked. Eric Elliott, author of Programming JavaScript Applications and a TDD advocate, even says mocks are code smells. Forgetting to mock also has its downsides.
As I’ve mentioned, unmock has taken a few twists and turns. Learning from our own mistakes, as well as from others’, we set out to bring a tool that’s as minimal and automatic as possible. You code, we mock. We stand out from the crowd and plethora of other mocking services, in that we’re a fully automated, JIT mocking service, with minimal intrusion to your codebase. Our SDK is essentially a one-liner (available in many languages). Behind the scenes, we track thousands of APIs and use state of the art NLP techniques to understand how the API should work. We intercept your tests requests and return a semantically coherent response. You no longer have to worry about mocking your content or accidentally hitting the real API.
We don’t stop there. We also provide a “flaky” mode to replicate the occasional missed requests and various errors in your target API. With our “random” mode, we provide non-deterministic responses, with the hopes of helping you discover additional bugs over the bigger course of development.
We’re also very fond of Pastebin and sharing content with your colleagues, so mocks are easily shareable. They’re also easily editable — both online (via the simple dashboard) and offline (with a simple text editor or with our vscode plugin). Speaking of dashboard, we also make it easy to see mock history (via the dashboard) and relate the different mocks to test suites (via the plugin).
Your mocks can also be stateful, and once unmocked, your unmocked responses are available for offline use as well (although then you can’t simulate the latency of making the request — which is not a bad thing, just something to keep in mind).
What’s next? As we grow and maintain a bigger database of APIs (at the moment we don’t really mock the entire internet — yet), we plan to spread out and provide unmock in other contexts. Microservices, API discovery (when no documentation is available), databases and more. Our SDK is available in 3 languages at the moment (JavaScript, Python, Java), and we plan on extending it for other languages as the need arises.
There are a few things that would make us extremely happy:
1. Saving your time when coding — test unmock. Play with it, try to break it, give it a shot. It’s free anyway.
2. Share your experiences (or favorite memes) with us; let us know how we can improve our product, what you did or didn’t enjoy.
3. Ping us if you’d like to work with us (we’re also hiring), or just have us in your next meetup! We attend Node and Python meetups quite regularly.
You code. We mock.
