[whateveracct]

I like to use Haskell and servant.

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.

[waynesonfire]

mocks are useful when you're able to make them return different data for different operations to support a test case.

what does your api look like for configuring your in-memory server mock? I assume your test cases would interface with this?

[whateveracct]

The mock is just an in-memory implementation of the service API I'm mocking. It's a bit more complex, but you have APIs to create entities, fetch them by id, etc. And you actually generate ids, store them, query them.

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.