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

51–60 of 63 posts

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

#51

Post by peheje »

anonymoushn wrote: post #41
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.

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…

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.

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

#52

Post by berkes »

paledot wrote: post #49
borland wrote: post #48

Earlier quoted context omitted.

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 o…

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.

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.

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

#53

Post by anonymoushn »

peheje wrote: post #51
anonymoushn wrote: post #41

Earlier quoted context omitted.

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…

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 replac…

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"

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

#54

Post by peheje »

anonymoushn wrote: post #53
peheje wrote: post #51

Earlier quoted context omitted.

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 replac…

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"

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.

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

#58

Post by disposedtrolley »

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

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

#59

Post by mdaniel »

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 ;-)

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

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

#60

Post by mdaniel »

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

Post reply on HN