11 ms·

Ask HN: Best Way to Mock APIs in 2020?

71 points by HiddenCanary 6y ago

I'm looking for a good way to Mock APIs for a sideproject, so far I haven't found any solution that has blown me away and I'm wondering If I'm missing anything. I'm curious what people recommend for the best way to Mock APIs?

zoontek 6y ago
Might not be the best, but the ones I use: For REST API: https://mockoon.com/ https://mockoon.com/ For GraphQL: https://github.com/APIs-guru/graphql-faker https://github.com/APIs-guru/graphql-faker
nmasse-itix 6y ago
I was wondering if you had a chance to have a look at Microcks (https://microcks.io/ https://microcks.io/) ?
- deleted 6y ago
  [deleted]
coold 6y ago
I'm using Wiremock
robjan 6y ago
Depends how advanced the mocking behaviour requirements are. For most projects, I find json-server sufficient. 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.
htyden 6y ago
https://intervene.dev/ https://intervene.dev/ has been very useful for me.
lbroudoux 6y ago
I would suggest having a look at Microcks (https://microcks.io https://microcks.io) as a way to produce mocks from OpenAPI contracts, Postman collection or other assets... Full disclosure : I am the founder of the project ;-)
- HiddenCanary 6y ago
  Nice! Have you considered doing a free online SaaS version, rather than a self-hosted k8s version?
  - lbroudoux 6y ago
    Yes it’s something we have in mind for next months or so.
- mdaniel 6y ago
  > Keycloak 4.8.0 > MongoDB 3.4 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?
jacobr 6y ago
Haven’t tried it yet, but https://www.npmjs.com/package/msw https://www.npmjs.com/package/msw looks very interesting. It uses Service Workers in the browser to intercept requests to the APIs, instead of running a real mock server. There’s support for mocking in Node as well for SSR and jsdom tests.
triztian 6y ago
I've found mitmproxy (https://mitmproxy.org https://mitmproxy.org) in reverse mode really useful. I'm a mobile dev and when the backend work is still pending I usually mock the backend requirements by selectively patching or adding endpoint support, it can be used like so: mitmproxy --mode reverse:https://my.privateapi.com -s ./path/to/mockscript.py This allows me to implement most of the UI and server interactions w/o being blocked by server work.
- e12e 6y ago
  Oh, this looks interesting. Thank you for the pointer. I think we can use both: https://docs.mitmproxy.org/stable/addons-scripting/ https://docs.mitmproxy.org/stable/addons-scripting/ For mocking, and dump/replay for debugging for some of our projects. https://docs.mitmproxy.org/stable/tute-clientreplay/ https://docs.mitmproxy.org/stable/tute-clientreplay/
tiborsaas 6y ago
I've used this: https://github.com/nock/nock https://github.com/nock/nock worked great for tests.
baggsie 6y ago
I've found Hasura to be great for this, maybe slightly more longer to set up but you get a full CRUD graphql setup for little effort.
peheje 6y ago
Can someone explain to me what this is all about? Shouldn't you hide all your API calls behind an interface, and then mock that interface? Dependency inversion principle, depend upon abstractions and all that.
- emilsedgh 6y ago
  I personally am not a fan of too many abstractions. If the only reason for abstraction is testing, then mocking an interface seems like a more valid choice to me.
  - xadoc 6y ago
    The abstraction is there because in many static languages you will immediately have two implementations, the infrastructure one (database, API call, 3rd party) and the tests.
  - jjpe 6y ago
    > I personally am not a fan of too many abstractions. 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.
    - TomMarius 6y ago
      This is definitely a valid approach to software development, e.g. in embedded development (where you still might need to call APIs).
    - emilsedgh 6y ago
      Absolutely. I'm not saying I don't want to abstract anything or deal with any abstractions which can lead to ridiculous code [0]. I just prefer to abstract when I have more reasons that just testing. That can be done using mocking techniques. https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/springframework/aop/config/SimpleBeanFactoryAwareAspectInstanceFactory.html https://docs.spring.io/spring/docs/2.5.x/javadoc-api/org/spr...
- 6y ago
xgenecloud 6y ago
If you have a database - try this https://github.com/xgenecloud/xgenecloud https://github.com/xgenecloud/xgenecloud 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 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
forresponse 6y ago
I've used this on multiple projects: https://github.com/typicode/json-server https://github.com/typicode/json-server
gerdusvz 6y ago
your mother was a SOAP request
- chrismorgan 6y ago
  I feel like that might have been better mockery for 2010 than 2020. While there’s something to be said for mockery that goes over someone’s head (so that you get to feel smugly superior, and they just feel vaguely discomfited because they can tell you were deriding them, but they’re not sure how), it can also be nice if they understand, so that they know just how insulted they should feel.
mpweiher 6y ago
Avoid mocking: https://blog.metaobject.com/2014/05/why-i-don-mock.html https://blog.metaobject.com/2014/05/why-i-don-mock.html
XVincentX 6y ago
https://stoplight.io/open-source/prism https://stoplight.io/open-source/prism
isuckatcoding 6y ago
Don’t bother with mock APIs tbh. I assume you’re trying to unit test the front end? If anytime, write integration tests using something like selenium or whatever the latest hotness is.
vkku 6y ago
Mockito exists as an option
- colecut 6y ago
  I like this endorsement
m0xte 6y ago
http://wiremock.org/ http://wiremock.org/ works for me
mister_hn 6y ago
Api-framework works really good for this
davegb3 6y ago
If you like wiremock, try https://intervene.dev https://intervene.dev - config in TypeScript with automatic https and CORS. Open for questions + feedback [author]
nerdywordy 6y ago
https://miragejs.com/ https://miragejs.com/ is a great complement to frontend first development. Some folks on my team use it and love it. I tend to dev from back to front so I don't run into the need as much. If I do I typically just mock a JSON response in my frontend call function. Depending on the need I'll sometimes set the call to return an error response as well.
mcintyre1994 6y ago
I’ve really liked working with mmock https://github.com/jmartin82/mmock https://github.com/jmartin82/mmock It has a nice API for inspecting the requests made to the mock server and a nice web UI for debugging too.
sidcool 6y ago
I use Mountebank extensively and it's a pleasure to use.
kahrensdd 6y ago
There are lots of variations depending upon your use case. 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.html 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/setting-up-mock/ 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://github.com/buger/goreplay https://docs.mitmproxy.org/stable/ 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/vcr/vcr https://github.com/bblimke/webmock 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.
thiht 6y ago
Shameless plug: I developed Smocker[1] for exactly this use case. It's not the only solution but we have a few features not present anywhere else that matched exactly our use case. Hope it can help you :) [1]: https://smocker.dev https://smocker.dev
pinacarlos90 6y ago
Use swagger-openAPI3 and generate a spec. You can then use the spec to spin up clients or import to a API management tool and produce mock data, with support for authentication and more. I recommend using swashbuckle (for .netCore) if you already have the code for your API, it allows you to quickly produce spec from code.
jcpst 6y ago
For a side project? I think that makes a difference here. 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.
lovetocode 6y ago
A lot of Ruby’s test frameworks have this functionality built in. What technology are you using
deleted 6y ago
[deleted]
poke111 6y ago
https://www.mock-server.com/ https://www.mock-server.com/
hckr_news 6y ago
Nock and JSON server are useful libraries
disposedtrolley 6y ago
If the API provider supplies an OpenAPI definition, you can give API Sprout a try. It’ll parse the definition and spin up a mock server returning the example data you want. You can also modify the OpenAPI definition manually if you need different data to be returned. https://github.com/danielgtaylor/apisprout https://github.com/danielgtaylor/apisprout
mdaniel 6y ago
I readily admit I haven't evaluated every one of the comprehensive URLs in this thread, but back when I was doing integration work between my project and both GitHub and Jira, I found the scripting support in SoauUI (https://github.com/smartbear/soapui/tree/release-5.5.0 https://github.com/smartbear/soapui/tree/release-5.5.0) allowed me to model some dynamic behavior, and use the fallback responses when I didn't care about specifying every single one of them Despite its name, SoapUI has strong support for REST, and with a little massaging maybe even GraphQL also
tomakehurst 6y ago
MockLab [1] is a SaaS mocking tool built on top of WireMock. Worth a look if you use Swagger/OpenAPI as it'll accept this as an import format. [1]: http://mocklab.io http://mocklab.io

pydry 6y ago

I've gone through this process a few times: 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.

bjterry 6y ago
> 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. 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.
moreaccountspls 6y ago
Totally agree with you. I think the industry is going through an "emperor has no clothes" thing with unit tests and dependency inversion at the moment. The creator of BDD gave this talk a few years ago, which resonated with me: https://www.youtube.com/watch?v=4Y0tOi7QWqM 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 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.

anonymoushn 6y ago

Some reasons not do to that: - 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.

borland 6y ago
What I find works well is to use dependency inversion to mock things out within your code, but mock out the transport layer. 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!
- paledot 6y ago
  All good points, but you missed the most important part: in any mature programming language, you're not implementing the HttpClient yourself: it's a library, package, bundle, whatever. Which means that when you mock that you're not missing out on testing any code that you wrote, and the project that maintains your HttpClient (hopefully) has their own community-maintained test suite.
  - berkes 6y ago
    Have a look at VCR. It was developed for Ruby, and does exactly that: mock out the actual HTTP part of your HTTPClient. It does this by first making the actual request and then storing that record in a plain YAML file (which you can alternatively generate yourself, by hand or from an openapi spec) Have a look at "Ports in Other Languages" in their README to find the VCR port for your language, framework or stack.
peheje 6y ago
1) Sure but that's the same as saying tests makes navigating the codebase harder because now when you "jump to usages" you find all the references from the tests. Probably fixable by tooling configuration. 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.
- anonymoushn 6y ago
  1) I haven't actually seen a tooling configuration that gives you the experience of having the concrete type in your code when you write code that uses an interface (in e.g. golang or Java) for the sole purpose of swapping it out in a test. 2) Right. I agree. 3) It looks like your original post in this thread says "Do not make black box tests. Make white box tests"
  - peheje 6y ago
    1) Me neither to be honest, but would love to see it. 3) All right. That was not my intend. I think they both do different stuff, some projects need both, some only need one or the other.