Your Tests That Make Network Requests Are Flaky

November 20, 2025

The Fallacy

One of the Fallacies of Distributed Computing is “the network is reliable.” It’s not. Networks drop, slow down, or just decide to misbehave mid-test. Any time your test depends on the network, you’re accepting those failure modes too.

That’s why network-bound tests flake in CI while passing locally. Your local machine has a fast, stable connection to itself. CI runners talk to external services over real networks with real latency, real packet loss, and real DNS hiccups.

The Damage of Flaky Tests

Flaky tests erode trust in the test suite. When a test fails and the first instinct is “just re-run it,” you’ve already lost. The team stops investigating failures, stops trusting green builds, and eventually stops writing tests for the parts of the system that are hard to test reliably.

This isn’t hypothetical. I’ve seen teams with 200-test suites where 15 tests are “known flaky.” Those 15 tests train the entire team to ignore test failures. And when a real bug causes a failure, it gets lost in the noise.

Mocks and Fakes Exist for a Reason

The solution is well-established: don’t hit the network in your unit and integration tests. Use mocks, stubs, and fakes to simulate external dependencies. Record and replay HTTP interactions for tests that need realistic responses.

But use them sparingly and intentionally. A test that mocks everything tests nothing. The goal is to isolate the specific behavior you’re verifying while keeping the test deterministic.

Contract tests verify that your mocks match reality. They run against the actual external service on a schedule (not on every commit) and alert you when the interface changes. This gives you the speed and reliability of mocks with the confidence of real integration.

The Right Layer for Network Tests

Save actual network requests for a small number of smoke tests or end-to-end tests that run in a controlled environment. These tests should be:

Clearly marked as network-dependent
Run separately from the main test suite
Expected to occasionally fail due to external factors
Never gating a deploy on their own

Your core test suite — the one that runs on every commit and blocks merges — should be deterministic. No network calls, no database dependencies, no file system assumptions. Fast, reliable, and trustworthy. That’s the foundation everything else builds on.

This article was originally posted on LinkedIn.