Is it only me that mocking server API is sooo hard?
Is it only me? Tried a bunch of services but oh man, setup and mock server API for my mobile app is soooo hard.
You can easily write a version of ServerConnection that returns local data instead of making network calls, and then later replace it with the real version that talks to the server.
If your backend is written in the same language, you now have the blueprint for the backend service too; you know exactly what methods it has to implement. You just need some boilerplate around it to turn JSON -> type A -> run f(A) -> type B -> return JSON.
If you're using a different language it would be nicer to have the API defined in a language-agnostic way; it's always possible to create that language-agnostic spec from your code that defines the interface/types.
I know Microsoft gets flack in HN, but I find this document a pretty good primer on API design and decisions you should make: https://docs.microsoft.com/en-us/azure/architecture/best-pra...
Now if you have to consume an API you have no control of make sure you are mocking at the right layer, aka mocking the response, not the actual call to the API.
A tool we use for generating mock data sets is Mockaroo.
Sometimes though, you just can’t replace having a real api with mock data. For that, we have our own sandbox environment that is a clone of our production stack. All the app data in our sandbox is generated by a library called Faker.
I encode the API as a servant type.
Implement a server with in-memory data structures.
I run the server and just change the endpoint the production client library hits. This is a language-agnostic mock.
But if there isn't a production client library yet, I get a Haskell client for free! And with a lot of work, could probably generate any language's HTTP client from the servant type for free.
what does your api look like for configuring your in-memory server mock? I assume your test cases would interface with this?
So for, say, the Slack API. You'd create a workspace and some channels. Send some messages. And then when you ask for the chat history of a channel, it'll be the actual messages you send.
Slack is a bit more complicated because it would also include webhooks. Not impossible to wire up and send realistic ones. But it's of course more (fixed-cost) work. But if your business relies on this API so much, maybe it's worth it.
The fun part is if you do it this way, you can - in theory at least - run your test suite both against your mock and against the real thing.
The big killer feature here is servant and Haskell make it relatively easy to do this. The code is not complicated and it's hard to mess up. It can just be tedious. But it's good work for a junior engineer or new hire or intern to do.
If you use docker there are quite a few mocker-in-a-box solutions.
I use Java and Node, and created something basic [1] that does this for testing.