I'm curious what people recommend for the best way to Mock APIs?
1) Join a project and fume about how they didn't write nice, clean, "testable" code.
2) Build some sort of integration testing framework that also mocks out REST API calls relatively cheaply (e.g. using recording/playback against a live system).
3) Realize that I can now refactor the code such that it is nice, clean and more easily "unit testable".
4) Realize that with an effective and easy to use, fast integration testing framework the lack of dependency inversion doesn't bother me nearly as much as it used to.
5) Wonder if dependency inversion is actually more of a hack to deal with the sheer utter crappiness of unit tests... and whether making vast architectural changes to code in order to accommodate the sheer ineffectiveness of the current state of test tooling is really the height of wisdom after all.
In a number of these projects there were noises about rewriting the whole damn thing in a different language (usually because management wanted to consolidate hiring around fewer languages), and it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests.
The creator of BDD gave this talk a few years ago, which resonated with me: https://www.youtube.com/watch?v=4Y0tOi7QWqM
> it occurred to me that it would actually be kind of great to write tests where the entire implementation including the language itself could be swapped out without really changing the tests.
This is exactly what I've been doing and advocating for for a while. Don't mock things like databases at all in your code. If you want to use a mock, use a "first class" mock like https://cloud.google.com/bigtable/docs/emulator.
The other thing is that TDD was born in a world where containers aren't the norm. All the pain of higher level testing really comes up from setting up an appropriate environment. If you're already using Docker or k8s, that pain is pretty much 0.
I think this basically already exists with "Cucumber" and behavior-driven development. The test definition is specified in a natural-language-looking DSL which supports a number of underlying languages. When you swapped out the system you would have to implement the step definitions in the new language, but the tests would remain valid.
- Now it's harder to navigate my codebase because I introduced an extra layer of indirection everywhere only for the sake of testing.
- If there is some difference between how the actual protocol client and actual upstream behave and how my fake interface behaves in test, my tests will be wrong, and I will find out when I push to prod. If my tests exercised the actual code that speaks the actual protocol to a fake upstream, I may have caught the issue in the tests.
- If I ever want to replace the process entirely with a completely different one, I must now throw away my tests. If my tests tested the end-to-end behavior of the system, I would be able to keep my tests.
2) For each unit test setup an independent mock of the interface for your subject-under-test. You should not create catch-all mocks for all your interfaces, unless it's to be used for offline work.
3) If you replace the process, as in the business process, you need to redo the tests as well yes. If you replace the implementation, you must throw away your "white-box" tests but should be able to keep your "black-box" tests.
I.e: If you have a "stack" like this:
- Application
- MainService
- ApiService
- HttpClient
What you might think of doing is replacing the ApiService with a mock, such that you can test your MainService's interactions with it.
You can do that, sure, and it's useful - but as you rightly point out now you can't find any bugs in your ApiService.
Instead, mock out the HttpClient (or if it's not Http, mock out the Socket). Typically because these kinds of things are at the bottom of the stack, they have very simple interfaces and are really easy to mock, and because the interfaces are so simple the mocks don't introduce much - if any - damage to the rest of your code around them.
There are significant advantages to doing it this way too, over using an external mocked API.
- Way faster
- More reliable
- Single codebase (if the mock API is some external NodeJS thing now you have to wrangle that too)
- You have perfect control over timing. For example, if you have a bug in your ApiService which happens when two packets get interleaved in exactly the wrong way, you can reproduce this easily. If you had a real HttpClient talking to an external process it's nigh impossible.
Good luck!
If the only reason for abstraction is testing, then mocking an interface seems like a more valid choice to me.
Then you're likely in the wrong business, since most of what programming is is dealing with the various facets of one abstraction or another.
How is that different then defining an API and then having stub methods on the front returning pretend data?
Both the API and the Mock implementation will require the same interface.
Full disclosure : I am the founder of the project ;-)
That's a pretty heavyweight dependency list (and I'll leave my snide remarks about Mongo out of this)
Does your usecase involve such high security for your mocks?
mitmproxy --mode reverse:https://my.privateapi.com -s ./path/to/mockscript.py
I think we can use both: https://docs.mitmproxy.org/stable/addons-scripting/
For mocking, and dump/replay for debugging for some of our projects.
Remember that perfect is the enemy of good enough. If you're looking to be blown away by your mock server you may never get round to building your product.
What I’ve been doing lately, in my own time outside of work, is setting up a postgres DB, pointing postgraphile to it, then I have the API out of the way.
From there, if I’m consuming that API in a statically-typed language, I’ll look at generating the models I need from the graphql schema with quicktype.
That process is usually quick enough that there’s no reason to mock.
I suppose if I was doing UI first, I would just have the repository layer that’s abstracting my calls to whatever just have a function that returns a dumb static object in the shape I expect.
For REST API: https://mockoon.com/
For GraphQL: https://github.com/APIs-guru/graphql-faker
For unit testing and CI you may want mock objects that are implemented in the same language as your code. Google search for "mock object <language>". That's where you'll find Mockito (Java) or Mocha Spy (NodeJS) or Testify (golang). This list never ends.
Specifically for unit testing of a UI, you may want your browser driver to handle this, ex: Cypress has built-in support for mock AJAX endpoints. https://docs.cypress.io/guides/guides/stubs-spies-and-clocks...
If you want an endpoint you can call, Postman has a feature for this, there are several others like this in the comments (JSON Server, mmock, mountebank, etc.). https://learning.postman.com/docs/postman/mock-servers/setti...
If you need to capture traffic, check out goreplay or mitmproxy: https://github.com/buger/goreplay https://docs.mitmproxy.org/stable/
There is a whole class of "VCR" projects for recording traffic, these tend to be language specific (VCR is in Ruby), but there are ports to other languages: https://github.com/vcr/vcr https://github.com/bblimke/webmock
The vendor products tend to be labelled Service Virtualization. I used to work for one of those companies, ITKO, we were acquired by CA Technologies (now Broadcom) in 2011. There are vendor products from Micro Focus, Tricentis, Broadcom, Parasoft, etc.
It's important to think about your use case: local development, unit testing, CI, integration testing, performance testing, recording vs. programming, protocol support, payload support, etc. Many of the tools focus on just a subset of these areas.
Despite its name, SoapUI has strong support for REST, and with a little massaging maybe even GraphQL also
Automatically generates REST & GraphQL APIs within seconds from your database schema.
Here is a demo on how to create 8000+ REST APIs within 10 seconds - https://youtu.be/NtCwnlLudnk
Not just mock - you may even consider writing the full backend on it.
Im the creator - happy to answer any questions.
edit : added demo link
There’s support for mocking in Node as well for SSR and jsdom tests.
Hope it can help you :)
[1]: https://smocker.dev
It has a nice API for inspecting the requests made to the mock server and a nice web UI for debugging too.
Worth a look if you use Swagger/OpenAPI as it'll accept this as an import format.
[1]: http://mocklab.io
Open for questions + feedback [author]
If anytime, write integration tests using something like selenium or whatever the latest hotness is.