Show HN: Mock – setup and test APIs easily | Hacker News Reader

Show HN: Mock – setup and test APIs easily

github.com

10 pointsdhuan_7 comments

One key motivation for building this was that, despite there being other similar tools out there, I wanted a utility that was language-agnostic, meaning I could make test assertions without having to write in some particular language. So Mock was designed this way where assertions are made by simply doing HTTP calls. Another point was installation - setting up Mock in your CI is a matter of just downloading the executable file, where other alternatives required me to install Java SDK, or Nodejs, or whathever programming language their utility was written in, resulting in CI scripts more complicated than what I wanted.

What is the use case for sending data then doing an assertion on the data that was stored? Or am I not understanding how assertions work.

Did you consider adopting the OpenAPI standard for specifying the mock endpoints and their responses?

There is another hosted mock Beeceptor.com

it has support for http mocking, intercepting, proxying, tunneling and single click OAS Mock setup.

No, I didn't think of that yet. But yes I can see the benefit. The thing is that Mock's endpoint configuration format enables you do custom things that afaik OpenAPI wasn't designed for. In Mock's endpoint configuration you can set routes to return different responses based on conditions - say if route such was requested with querystring values such and such, then such response would be returned, and so on.

Imagine for example mocking MediaWiki's API where you have a single "api.php" endpoint, where you determine the "action" of the API operation with querystrings. Mock was used here to mock their API enabling me to easily do E2E tests: https://github.com/dhuan/wikicmd/blob/master/tests/e2e/mock/...

Ah, I understand now.

As a potential user though, I think if the tool worked with the OpenAPI one way or another, I'd be able to mock a service's API much faster. For example, maybe it can ingest OpenAPI and transpile it to your tool's schema. Or maybe your tool's schema could be a superset of OpenAPI.

Whichever implementation you choose, as long as it helps me avoid rewriting parts of the config that can easily be inferred from existing docs/schemas, that'd be a huge win.

Makes sense. Thanks for the suggestion. Indeed it'd be convenient to have that one day.

Reply on news.ycombinator.com