Introduction

Mocking HTTP requests means replacing real network calls with controlled test behavior so your code can be verified without depending on external services. The right mocking technique depends on what you are testing: your own request-building logic, the code that consumes the response, or the full client-server interaction path.

Decide What Layer You Want to Fake

There are three common testing levels.

The first is pure unit testing, where you replace the HTTP client call entirely and return a fake response object.

The second is request interception, where a real client library runs but outgoing HTTP is intercepted before it hits the network.

The third is integration-style mocking, where you run a local fake server and let the code talk over actual HTTP.

Each level has different tradeoffs between speed, realism, and maintenance cost.

Mocking in Python With unittest.mock

If your code uses requests.get, a unit-test approach is often enough.

1from unittest.mock import patch, Mock
2import requests
3
4
5def fetch_status(url):
6    response = requests.get(url)
7    response.raise_for_status()
8    return response.json()["status"]
9
10with patch("requests.get") as mock_get:
11    fake_response = Mock()
12    fake_response.json.return_value = {"status": "ok"}
13    fake_response.raise_for_status.return_value = None
14    mock_get.return_value = fake_response
15
16    print(fetch_status("https://example.com/api"))

This style is fast and precise, but it tests your code against a mocked requests API, not against real wire behavior.

Mocking in JavaScript With fetch

In browser or Node-based tests, a common pattern is to replace fetch.

1async function loadUser() {
2  const response = await fetch("/api/user");
3  const data = await response.json();
4  return data.name;
5}
6
7global.fetch = async () => ({
8  ok: true,
9  json: async () => ({ name: "Ava" })
10});
11
12loadUser().then(console.log);

This is enough for many unit tests, but the fake response should mimic the parts of the real response object your code actually uses.

Simulate Error Cases Too

Good mocks do not only test the happy path. They should also cover:

• non-200 status codes
• malformed JSON
• timeouts
• connection failures
• empty or partial payloads

A test suite that only verifies successful responses gives false confidence about network-heavy code.

For example, in Python:

1from unittest.mock import patch
2import requests
3
4with patch("requests.get", side_effect=requests.exceptions.Timeout):
5    try:
6        requests.get("https://example.com")
7    except requests.exceptions.Timeout:
8        print("timeout simulated")

When a Fake Server Is Better

If your code builds headers, query strings, or request bodies in a complicated way, mocking the client call may hide important bugs. In that case, a local fake server or request-interception library is often better because the code still constructs a real HTTP request.

That helps catch problems such as:

• wrong URL paths
• missing headers
• bad JSON serialization
• incorrect HTTP methods

The more your test depends on actual HTTP semantics, the more useful higher-fidelity mocking becomes.

Keep Mocks Honest

The biggest testing risk is a mock that does not behave like the real service. Over time, the production API changes while the test double stays frozen, and the tests keep passing for the wrong reasons.

To reduce that risk:

• mock only the parts you need
• keep response shapes realistic
• include negative-path tests
• add a few integration tests against a real or contract-verified endpoint when possible

Mocking is a tool for isolation, not a replacement for every form of end-to-end validation.

Common Pitfalls

The biggest mistake is mocking too low in the stack and never verifying that the request itself is formed correctly.

Another mistake is returning fake responses that do not match the real client's interface, such as forgetting json() or raise_for_status().

A third issue is testing only successful responses and never simulating network failure or bad data.

Finally, global mocks such as patched fetch should be cleaned up between tests so one test does not leak behavior into another.

Summary

• Mock requests at the layer that matches the kind of confidence you need.
• Use simple client-call mocks for fast unit tests.
• Use interception or fake servers when request construction itself matters.
• Mock error cases, not just successful responses.
• Keep mock response objects realistic enough to match the real client API.
• Treat mocking as part of a balanced testing strategy, not the whole strategy.