How it works

The explanation, with examples you can run.

Three doubles in one test

The sign-up service below takes its dependencies as parameters. The test passes in a fake user store, a stub clock and a spy mailer, then checks the outcome. No database, no real time, no email.

Your code

function makeSignup({ users, mailer, clock }) {
  return async function signup(email) {
    if (await users.findByEmail(email)) return { ok: false, reason: "taken" }
    const user = { email, createdAt: clock.now() }
    await users.save(user)
    await mailer.send(email, "Welcome!")
    return { ok: true, user }
  }
}

// Fake: a working store that keeps rows in memory
function fakeUsers() {
  const rows = new Map()
  return {
    findByEmail: async (email) => rows.get(email) ?? null,
    save: async (user) => { rows.set(user.email, user) },
  }
}
// Stub: a canned answer
const fixedClock = { now: () => "2026-01-01T00:00:00Z" }
// Spy: does nothing useful, but remembers every call
function spyMailer() {
  const sent = []
  return { sent, send: async (to, subject) => { sent.push({ to, subject }) } }
}

async function main() {
  const users = fakeUsers()
  const mailer = spyMailer()
  const signup = makeSignup({ users, mailer, clock: fixedClock })

const first = await signup("ada@example.com")
  const second = await signup("ada@example.com")

console.log("first:", first.ok, first.user.createdAt)
  console.log("second:", second.ok, second.reason)
  console.log("emails sent:", mailer.sent.length)
}
main()

⌘/Ctrl + Enter

OutputNot run yet

Press Run to see what your code prints, in order.

Runs in this browser, in an isolated frame with no access to this page. console.log, info, warn and error are shown; code runs as a classic script, so use an async function for await.

The fake is what makes the second call meaningful: because it really stores the first user, the "taken" path is tested without a hand-written stub for each case.

With a framework

Vitest and Jest come with spies, mocks and fake timers built in. The same ideas, less code:

1import { expect, test, vi } from "vitest"2import { fakeUsers, makeSignup } from "./signup" // the functions from the example above3 4test("sends one welcome email", async () => {5  vi.useFakeTimers()6  vi.setSystemTime(new Date("2026-01-01T00:00:00Z"))7  const send = vi.fn().mockResolvedValue(undefined)8 9  await makeSignup({ users: fakeUsers(), mailer: { send }, clock: { now: () => new Date().toISOString() } })("ada@example.com")10 11  expect(send).toHaveBeenCalledTimes(1)12  expect(send).toHaveBeenCalledWith("ada@example.com", "Welcome!")13  vi.useRealTimers()14})

When doubles hurt

Over-mocking: if a test replaces every collaborator, it tests only that the code calls things in a certain order. Refactor, and it fails. Introduce a real bug in a collaborator, and it still passes.
Mocking what you don't own: hand-written stubs of a third-party SDK capture what you think it does. Wrap the SDK in a small adapter of your own, double the adapter in unit tests, and test the adapter itself against the real thing (or a container) in an integration test.
Stale stubs of other services: every stubbed HTTP response is a claim about another team's API. Contract tests are how you keep those claims true.

A useful rule: double things that are slow, non-deterministic or outside your control. Keep plain logic and value objects real.

Check yourself

3 questions. Get them all right to finish this topic.

1.An in-memory repository with working save and find methods, used in place of the database in tests, is a:
2.Your tests stub the payment provider's HTTP response. The provider renames a field. What happens?
3.Which kind of double is given its expected calls before the act step, and fails the test itself when they don't happen?

0 of 3 right so far. Get all three to finish this topic.

Test doubles: stubs, spies, mocks and fakes

How it works

Three doubles in one test

With a framework

When doubles hurt

Check yourself

Go deeper