---
title: "Test Doubles and Testing at a Boundary"
description: "To test code that talks to a database, a clock or a network, the test replaces that neighbour with a stand-in it controls. The choice of where to put the seam decides whether the test survives a refac"
canonical: https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM
source: https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM.md
retrieved: 2026-09-12
---

> **Agent view.** This is the Markdown twin of the page, for tools and assistants.
> When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md
> API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md
> Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt
> Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json
> Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`.

# Test Doubles and Testing at a Boundary

To test code that talks to a database, a clock or a network, the test replaces that neighbour with a stand-in it controls. The choice of where to put the seam decides whether the test survives a refactoring or breaks on every change.

Subject: Computing · Area: Software Engineering · Ages 20 to 21
Page: https://lightmysky.com/learn/computing/test-doubles-and-testing-at-a-boundary-mt_4ep3SiMYNM

## Ready when they can

- Replace a real dependency with a stand-in and test the logic around it
- Distinguish a stub that returns canned answers from a mock that checks calls
- Explain why a test that asserts on internal calls breaks during refactoring

## Lesson: Stand-ins for awkward neighbours

You already know a unit test checks one small piece of code. When that code talks to a database, a clock, or a network, you replace the neighbour with a stand-in you control. The seam is the place where you plug the stand-in in.

**Example.** A function greets you differently before and after noon by reading the clock. In the test you swap the real clock for a fixed one that always says 9 in the morning. Now the result is predictable and the test never depends on the hour.

A stub is a stand-in that returns canned answers, such as a database that always returns the same row. A mock is a stand-in that also records which calls it received, so the test can check the code asked for the right thing.

**Tip.** Put the seam at the boundary of your code, and check the outward result rather than every internal call. Tests that assert on internal calls break on every refactoring, while tests on results survive it.

**Recap.** Replace awkward neighbours with stand-ins at the boundary, and check results instead of calls so refactors survive.

## Practice

8 questions on this page, each with its working shown.

## Needs first

- [Interfaces, Coupling and What a Module Promises](https://lightmysky.com/learn/computing/interfaces-coupling-and-what-a-module-promises-mt_EUZyD26WFk)
- [Refactoring: Changing Structure Without Changing Behaviour](https://lightmysky.com/learn/computing/refactoring-changing-structure-without-changing-behaviour-mt_HHZufOyTg4)

## Opens up

- [Test Strategy: Unit, Integration and End to End](https://lightmysky.com/learn/computing/test-strategy-unit-integration-and-end-to-end-mt_fdAvx1MMFE)