Mocking: Faking Dependencies in Unit Tests

Why it exists

Unit tests must be fast, reliable, and deterministic. Code that depends on external systems—like network APIs, databases, or hardware sensors—is none of those things. Mocking was created to isolate the code you're testing from these slow and unpredictable dependencies.

The mental model

A mock is a "stunt double" for a real object. It has the same public API as the real thing but a fake implementation you control in your test. You can command the mock to behave in specific ways, like "pretend the network request failed" or "return this specific data." This allows you to verify that your code reacts correctly to every possible outcome, without needing a live internet connection or a physical device.

How it works

The core technique enabling mocking is dependency injection. Instead of having an object create its own dependencies (e.g., let session = URLSession.shared), it should accept them in its initializer. In your production code, you inject the real object. In your test code, you inject the mock. A common way to create a mock in Swift is to subclass the real object (e.g., class URLSessionMock: URLSession) and override its methods. The overridden method contains test-specific logic, like returning a pre-set data object or error instead of performing the real action.

When to use it

Use mocks when your code interacts with an external dependency you cannot or should not control in a test. Three classic cases are: first, faking network clients to avoid slow, flaky tests that require an internet connection; second, simulating system services like location or motion sensors; third, isolating your code from complex objects with their own state.

When not to use it

Avoid mocking simple value types or objects with pure logic. Excessive mocking is a footgun; your tests can become so decoupled from reality that they pass even when the integrated system is broken. If a dependency is simple and fast, consider using the real object to ensure your test is more realistic.

One canonical example

To test a NetworkManager that fetches data using URLSession, you would create a URLSessionMock. You would inject this mock into your NetworkManager during the test. In your test setup, you'd configure the mock to return specific data on success or a specific error on failure. Then, you can write separate tests to verify that your NetworkManager correctly handles both the success and failure paths, all without ever making a real network call.