Fakes, stubs, and mocks.

01 / The idea

A test double is a choice about the boundary.

The alert rule is small: read a forecast, read the time, and send a notification only when rain risk is high. The weather provider, clock, and notifier are collaborators. They are also places where a test can lose speed, determinism, or focus.

Replacing a collaborator is not automatically “good isolation.” A canned forecast proves what the policy does with that answer, but it does not prove the provider parses a real response. A working fake exercises more flow, but it still is not the provider. A call log shows behavior, while an exact expectation can bind a test to details nobody promised.

Keep the behavior under test real; replace only the boundary the test needs to control.

// This first version is easy to call, but time is hidden inside the policy.
export function directAlert(
	city: string,
	readForecast: ForecastReader,
	notify: Notifier
): AlertResult {
	const forecast = readForecast(city);
	const checkedAt = new Date().toISOString();
	if (forecast.rainProbability < rainThreshold) {
		return { status: 'skipped', city, checkedAt, reason: 'rain risk is below the threshold' };
	}
	const notification: Notification = {
		channel: 'weather',
		city,
		body: `${city}: rain is likely today`,
		checkedAt
	};
	notify(notification);
	return { status: 'sent', city, checkedAt, notification };
}

02 / See the shape

Name what each replacement gives you.

The practical service takes three explicit ports: readForecast, now, and notify. A stub can return a rainy forecast. A fake can store forecasts and sent messages in memory. A spy can collect calls for a behavioral assertion. A mock-like test can add a precise expectation when the call itself is a contract.

export function alertForRain(city: string, ports: AlertPorts): AlertResult {
	const checkedAt = ports.now();
	const forecast = ports.readForecast(city);
	if (forecast.rainProbability < rainThreshold) {
		return { status: 'skipped', city, checkedAt, reason: 'rain risk is below the threshold' };
	}
	const notification: Notification = {
		channel: 'weather',
		city,
		body: `${city}: rain is likely today`,
		checkedAt
	};
	ports.notify(notification);
	return { status: 'sent', city, checkedAt, notification };
}

func AlertForRain(city string, ports AlertPorts) AlertResult {
	checkedAt := ports.Now()
	forecast := ports.ReadForecast(city)
	if forecast.RainProbability < rainThreshold {
		return AlertResult{Status: "skipped", City: city, CheckedAt: checkedAt, Reason: "rain risk is below the threshold"}
	}
	notification := Notification{
		Channel:   "weather",
		City:      city,
		Body:      city + ": rain is likely today",
		CheckedAt: checkedAt,
	}
	ports.Notify(notification)
	return AlertResult{Status: "sent", City: city, CheckedAt: checkedAt, Notification: &notification}
}

func AlertForRain(city string, ports AlertPorts) AlertResult {
	checkedAt := ports.Now()
	forecast := ports.ReadForecast(city)
	if forecast.RainProbability < rainThreshold {
		return AlertResult{Status: "skipped", City: city, CheckedAt: checkedAt, Reason: "rain risk is below the threshold"}
	}
	notification := Notification{
		Channel:   "weather",
		City:      city,
		Body:      city + ": rain is likely today",
		CheckedAt: checkedAt,
	}
	ports.Notify(notification)
	return AlertResult{Status: "sent", City: city, CheckedAt: checkedAt, Notification: &notification}
}

03 / Follow the boundary

Watch the replacement change what you can know.

The frames keep the alert policy constant. First the clock is hidden. Then one stub controls the forecast. A fake makes a small weather world observable. Finally a spy records the notifier boundary without insisting on every internal call.

What the choice buys you

Each double answers a different testing question.

04 / Try a decision

Choose the smallest double for the claim.

You need to test the real alert policy’s rainy branch. The weather provider is slow, and the test does not need to verify its HTTP parsing. What should the test replace?

05 / Give it a real job

Make the seam useful beyond the test file.

Dependency injection is not a prize for having many parameters. It is a way to make a meaningful boundary explicit. Keep ports small, pass them at the composition edge, and let production wire the real forecast reader, clock, and notifier while tests choose replacements.

Use a stub for one branch, a fake for a small flow, a spy for an observable side effect, and a mock-like expectation only when the interaction is part of the contract. Then cover the real provider and notifier separately at their boundary.

type AlertView = {
	city: string;
	status: 'sent' | 'skipped';
	label: string;
	checkedAt: string;
};

type WeatherAlertProps = { alert: AlertView };

export function WeatherAlert({ alert }: WeatherAlertProps) {
	return (
		<article aria-label={`${alert.city} weather alert`}>
			<strong>{alert.status === 'sent' ? alert.label : 'No alert'}</strong>
			<small>Checked {alert.checkedAt}</small>
		</article>
	);
}

06 / Recognize it elsewhere

Look for boundaries with a different cost profile.

The names change, but the choice stays recognizable.

07 / Already in your toolbox

Most mocking tools implement several roles at once.

A library may call something a mock, spy, stub, or fake differently. Do not let the label decide the test. Ask what the replacement does and what question the assertion answers.

08 / The parts to watch

A convenient double can make a misleading test.

09 / Make the call

Choose by the question, not by habit.

Replace the smallest boundary that buys control.

Pair isolated tests with real-boundary tests for the behavior the double cannot exercise.

10 / Take the idea with you

Explain the alert test without saying “mock.”

“The alert rule runs for real. The forecast is a canned answer of 85% rain for Istanbul, the clock is fixed at 09:00, and we recorded the one notification it sent. The test never talks to the weather provider, so a separate test checks that we parse its responses.” That tells a reviewer what is real, what is replaced, and what is left unchecked. When they want the words, they are stub, fake, spy, and mock.

Before moving on, jot down which of the three ports you would replace to test the 70% threshold, what that test can no longer see, and one test in your own code that replaces the very thing it claims to check.