Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Best Way to Mock APIs in 2020?

news.ycombinator.com

Post reply on HN
Print view View original

31–40 of 63 posts

Re: Ask HN: Best Way to Mock APIs in 2020?

#31

Post by emilsedgh »

jjpe wrote: post #18
emilsedgh wrote: post #14

Earlier quoted context omitted.

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.

> 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.

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/spr...

Re: Ask HN: Best Way to Mock APIs in 2020?

#34

Post by nerdywordy »

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.

Re: Ask HN: Best Way to Mock APIs in 2020?

#37

Post by djohnston »

peheje wrote: post #12

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.

What does mocking an interface mean, like a mock implementation?

How is that different then defining an API and then having stub methods on the front returning pretend data?

Re: Ask HN: Best Way to Mock APIs in 2020?

#38

Post by lbroudoux »

HiddenCanary wrote: post #29
lbroudoux wrote: post #7

I would suggest having a look at Microcks ( 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 ;-)

Nice! Have you considered doing a free online SaaS version, rather than a self-hosted k8s version?

Yes it’s something we have in mind for next months or so.

Re: Ask HN: Best Way to Mock APIs in 2020?

#39

Post by pydry »

peheje wrote: post #12

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.

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.

Re: Ask HN: Best Way to Mock APIs in 2020?

#40

Post by kahrensdd »

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 ". 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.

Post reply on HN