DEV Community: moath othman

Backend not ready? Mock it at the proxy, from the OpenAPI spec you already have

moath othman — Fri, 13 Nov 2026 12:56:43 +0000

The screen is designed, the client code is written, and the endpoint it needs ships "next sprint". Every frontend and mobile developer knows this week. Here are three ways to stop waiting, when each one is the right call, and the edge cases you should be mocking anyway, even after the real API exists.

Option 1: mock inside the app

Fixtures, a fake HTTP client, or a request-interception library such as MSW for web and Node.

Good for: unit and component tests, fast feedback, no network at all.

Weak at: anything outside the test runner. A tester on a real device gets the real (missing) endpoint, and the mock code is one more thing that drifts from the spec.

Option 2: run a standalone mock server

Point a mock server such as Stoplight Prism at your spec and switch the app's base URL to it.

Good for: a whole API that does not exist yet, contract-first teams, local development.

Weak at: mixing. It mocks everything, so the endpoints that already work in staging are mocked too, and the app needs a different base URL (which means a different build or config) to use it.

Option 3: mock at the proxy

Route the app through a debugging proxy that answers only the endpoints that are missing and passes everything else to the real backend. The app keeps its real URLs, so nothing changes in the code when the endpoint ships: you delete the mock.

Good for: one or two missing endpoints in an otherwise real API, manual testing on real devices, and QA testing against the same mocks as the developers.

Weak at: the usual proxy setup. The device has to use the proxy and trust its CA.

The edge cases worth mocking even when the API exists

A mock that only returns the happy path is half a mock. For every list or detail endpoint, try:

Response	What it tells you
Empty list `[]`	Is there an empty state, or a blank screen?
`401`	Does the app refresh the token or log the user out cleanly?
`404` on a detail route	Does a deleted item crash the screen?
`500`	Is there an error state with a way to retry?
A 3 second delay	Is there a loading state, and can the user leave?
Malformed JSON	Does the parser failure crash the app or get handled?

The backend will almost never produce these on demand. A mock produces them in seconds.

The shared version

(17-second animated explainer, not a screen recording.)

Disclosure: I build Proxycept, a hosted debugging proxy, and option 3 is what it does for mocks. You upload an OpenAPI 3 spec or a Postman collection and get a mock route per operation; response bodies come from the spec's examples, or from placeholders built from the schema when there are none. Then you edit a route to return what you need: an empty list, a 401, a 500, or a delay. Anything you have not mocked goes to the real backend, unless you turn on catch mode, which blocks everything that is not mocked (handy for proving a demo or a test run has no hidden live dependency).

Because the proxy is hosted, the phone on a tester's desk, the emulator on your laptop and a CI runner all hit the same mocks through one endpoint. When something looks wrong, you can share the capture as a read-only link instead of a screenshot.

The limits: each device still has to trust the proxy's CA (manual on Android, like with any proxy), it does not get past certificate pinning, and it is for testing your own apps. If everything you test runs in one browser, option 1 is probably enough.

Free plan to start, sign in with Google, GitHub or email: proxycept.com. Related, if you want to capture real responses and replay them later: record and replay HTTP requests.

Which option does your team use, and what made you pick it? I'd like to hear it in the comments.

Your error handling has never met a real 503. Here's how to introduce them.

moath othman — Thu, 12 Nov 2026 20:12:31 +0000

Staging is a terrible place to test failure. It only ever produces the happy path, so the code that handles timeouts, 500s and retries is the least-executed code in most apps, right up until production executes it for you.

This post is a practical way to fix that without changing the backend or the app: make the failures happen at the proxy, between the two.

Three kinds of failure worth testing

Slow. The request succeeds, eventually. What does the UI show at 200 ms, at 3 seconds, at 30? Is there a spinner, a timeout, a way out? Does the user tap the button twice?

Broken. 500, 502, 503, a dropped connection. Does the app retry, and how often? Does it honour Retry-After? On a checkout, does a retry charge the card twice?

Wrong. The one people skip. An HTTP 200 with bad data inside: a price that arrives as "49.00" instead of 49.00, a field that is suddenly null, an empty list on a screen that always had one item. These break more UIs than 5xx errors do, and no backend will produce them on demand.

Why the proxy is the right place

You could fake these in the app (a mock HTTP client, test fixtures) or in the backend (a broken build on staging). The proxy layer beats both for this job:

It needs no code change on either side, so you are testing the build you will ship.
It works for manual, exploratory testing on a real phone, where there is no test harness at all.
The same setup applies to the app, the automation suite and CI.
You can target one host and one path, and leave everything else alone.

The trade-off is the usual proxy setup: the device or runner sends its traffic through the proxy, and trusts the proxy's CA so HTTPS can be decrypted. That is the same for every tool in this post, and it is the part worth doing once, carefully.

What to look for when it fails

A checklist that has found real bugs for me:

Does a slow request ever give the user a way out, or is it a spinner forever?
After a 503, does Retry respect Retry-After, or hammer the server?
On payment or order endpoints, can a retry create a duplicate?
Does the error message make sense to a user, or does it print payment_unavailable?
When a number arrives as a string, does the screen crash, show NaN, or quietly do maths on text?
After the failure clears, does the app recover without a restart?

When the proxy has to be shared

Everything above runs on one laptop, which is fine until the failure you care about happens on a device in the lab, on a teammate's phone, or in a CI run. Then the proxy has to be somewhere everything can reach.

(15-second animated explainer, not a screen recording.)

Disclosure: that is the problem I build Proxycept for. It is a hosted debugging proxy: phones, emulators, teammates and CI runners point at one authenticated endpoint, and captures land in one shared web console. In it you can hold a request and change its response before releasing it, set delays and error rates per profile or per route, and add response rewrite rules that change one field of a real response (keeping its JSON type, or deliberately changing it) while the backend still answers for real.

What it does not do: it does not get past certificate pinning, it does not remove the CA step on each device (on Android that step is manual, like with any proxy), and it is for testing your own apps. If you work alone on one machine, a desktop proxy like Charles, Proxyman or mitmproxy is all you need.

If the shared version sounds useful, there is a free plan, and you can sign in with Google, GitHub or email: proxycept.com. If you are comparing it with Charles, this page covers when each one fits.

Have a failure case I missed, or a bug story like these? I'd like to hear it in the comments.