Test doubles and testable design

The problem

How do you test a function that sends an SMS, reads today's date, or calls a payment gateway? You cannot send real SMS on every test run, the date changes every day, and the gateway charges money. Tests must be fast, repeatable and free. So you replace those parts with stand-ins during the test. A stand-in is called a test double (like a stunt double in a film).

Kinds of test doubles

Dependency injection: pass things in

Dependency injection means a function receives the things it depends on (fetch, the clock, a database object) as parameters instead of reaching for globals. Then a test can pass in a double. It sounds fancy, but it is just "use parameters".

// Hard to test: uses the real clock and the real SMS service
function sendReminderHard(user) {
  if (new Date().getHours() >= 21) return 'too late';
  return realSmsService.send(user.phone, 'Your appointment is tomorrow');
}

// Easy to test: dependencies come in as parameters (with real defaults)
function sendReminder(user, { now = () => new Date(), sms = realSmsService } = {}) {
  if (now().getHours() >= 21) return 'too late';
  return sms.send(user.phone, 'Your appointment is tomorrow');
}

A hand-made spy

function makeSpy(returnValue) {
  const spy = (...args) => { spy.calls.push(args); return returnValue; };
  spy.calls = [];
  return spy;
}
const send = makeSpy('sent');
const result = sendReminder({ phone: '9876543210' }, {
  now: () => new Date(2026, 0, 15, 10, 0),   // stub: always 10 a.m.
  sms: { send },
});
console.log(result, send.calls); // 'sent' [['9876543210', 'Your appointment is tomorrow']]

With Vitest or Jest

import { vi, it, expect } from 'vitest';
it('sends one SMS before 9 p.m.', () => {
  const send = vi.fn().mockReturnValue('sent');      // a mock function
  sendReminder({ phone: '98…' }, { now: () => new Date(2026, 0, 15, 10), sms: { send } });
  expect(send).toHaveBeenCalledTimes(1);
});
// vi.useFakeTimers() / vi.setSystemTime(...) control setTimeout and Date in tests.

Flaky tests

A flaky test sometimes passes and sometimes fails without any code change. Causes: real time and timers, randomness, real network calls, tests that depend on each other's order, or shared state left over from another test. Fix them by controlling time and randomness with doubles, and by giving every test its own fresh data.

Snapshot tests (in brief)

Snapshot tests save the output of a function (for example a rendered component or a big object) to a file the first time, and fail if it changes later. They are quick to write but easy to update without thinking. Review snapshot changes as carefully as code changes.