Designing code you can test

// ❌ The decision and the clock are tangled together
export function dueLabel(dueAt: number): string {
  const hoursLeft = (dueAt - Date.now()) / 3_600_000;
  if (hoursLeft < 0) return "Overdue";
  if (hoursLeft < 24) return `Due in ${Math.ceil(hoursLeft)}h`;
  return "Due later";
}

To test "Overdue" you need a dueAt in the past relative to whenever the test runs. So the test computes it from Date.now() — re-implementing the logic it's meant to check — or installs fake timers, or is green today and red at midnight. The function is hard to test because it reads something that isn't one of its arguments.

Move that read out, and pass the value in:

// ✅ Pure: everything it depends on arrives as an argument
export function dueLabel(now: number, dueAt: number): string {
  const hoursLeft = (dueAt - now) / 3_600_000;
  if (hoursLeft < 0) return "Overdue";
  if (hoursLeft < 24) return `Due in ${Math.ceil(hoursLeft)}h`;
  return "Due later";
}

const NOON = Date.UTC(2026, 2, 10, 12);

it("labels a task by the time left", () => {
  expect(dueLabel(NOON, NOON - 1)).toBe("Overdue");
  expect(dueLabel(NOON, NOON + 90 * 60_000)).toBe("Due in 2h");
  expect(dueLabel(NOON, NOON + 30 * 3_600_000)).toBe("Due later");
});

No doubles, no fake timers, no setup. The caller — the thin shell — supplies the real value: dueLabel(Date.now(), task.dueAt).

A pure function returns the same output for the same inputs and changes nothing outside itself. react.dev's two-line version: it "minds its own business", and "same inputs, same output". The usual reasons a function isn't pure, each of which belongs in the shell:

• the time — Date.now(), new Date()
• randomness — Math.random(), crypto.randomUUID()
• I/O — fetch, the database, localStorage, the file system
• the environment — process.env, window.location
• state that outlives the call — a module-level variable

Keep the decisions in a pure core and push those reads to the edge. The core gets tested with plain values; the shell is so thin there's little left in it to get wrong.

A task list that fetches, filters, sorts and labels — all inside the component:

export function TaskList({ filter }: { filter: "all" | "overdue" }) {
  const [tasks, setTasks] = useState<Task[]>([]);
  useEffect(() => {
    fetch("/api/tasks").then((r) => r.json()).then(setTasks);
  }, []);

  const visible = tasks
    .filter((t) => filter === "all" || t.dueAt < Date.now())
    .sort((a, b) => a.dueAt - b.dueAt);

  return (
    <ul>
      {visible.map((t) => (
        <li key={t.id}>{t.title} — {dueLabel(Date.now(), t.dueAt)}</li>
      ))}
    </ul>
  );
}

To test "overdue tasks come first, sorted by due date" you have to render the component, intercept fetch, wait for the effect, fake the clock, and read the order out of the DOM. The rule you care about is three lines; the test is thirty.

Split it by job:

// tasks.ts — pure. No React, no fetch, no clock.
export function visibleTasks(tasks: Task[], filter: "all" | "overdue", now: number): Task[] {
  return tasks
    .filter((t) => filter === "all" || t.dueAt < now)
    .toSorted((a, b) => a.dueAt - b.dueAt);
}

// TaskList.tsx — the shell: fetches, owns the clock, renders
export function TaskList({ filter, now }: { filter: "all" | "overdue"; now: number }) {
  const tasks = useTasks(); // the fetch lives in a hook
  return (
    <ul>
      {visibleTasks(tasks, filter, now).map((t) => (
        <li key={t.id}>{t.title} — {dueLabel(now, t.dueAt)}</li>
      ))}
    </ul>
  );
}

Now each rule is a one-line test in the Node environment — no DOM at all:

expect(visibleTasks([later, earlier], "all", NOON).map((t) => t.id)).toEqual([earlier.id, later.id]);
expect(visibleTasks([pastDue, future], "overdue", NOON)).toEqual([pastDue]);

and the component needs one rendering test to prove the wiring, not one per rule.

Three things moved, each for a reason:

• The decision went to a .ts file with no imports from React. That file can be tested as fast as any function, and reused on the server.
• The fetch went to a hook. One place handles loading and errors; the component stops caring.
• The clock became a prop. A component that calls Date.now() while rendering returns different output for the same props and state. React assumes "every component you write is a pure function"; react.dev's own clock example keeps new Date() and setInterval in a hook and passes time to the component as a prop.

toSorted returns a new array (ES2023); sort would reorder the array the caller passed in — a side effect hiding inside a "pure" function.

The claim is half true, which is why it survives. Vitest has no problem with enums: under Vitest 4.1 (Vite 8), a test importing enum Status { Active = "active" } from another file passes, and so does one importing a const enum declared in a .ts file. The claim comes from four other places. Each was checked by running it.

1. Node's own test runner on .ts files. Node strips TypeScript types by default since 22.18 and 23.6 (stable since 24.12 and 25.2), and node --test picks up *.test.ts. Stripping only erases types. An enum isn't a type — it compiles to a JavaScript object — so there's nothing to erase, and Node 24 refuses the file:

SyntaxError [ERR_UNSUPPORTED_TYPESCRIPT_SYNTAX]: TypeScript enum is not supported in strip-only mode

The old escape hatch, --experimental-transform-types (added in Node 22.7), was removed in Node 26.

2. erasableSyntaxOnly (TypeScript 5.8+). Projects that run through type stripping turn this on so the type checker reports what Node would reject. It errors on enum and const enum alike — everywhere, tests included:

status.ts(1,13): error TS1294: This syntax is not allowed when 'erasableSyntaxOnly' is enabled.

3. An ambient const enum under a per-file transpiler. A declare const enum — usually met in a library's .d.ts — has no JavaScript object at all; tsc replaces each use with the literal value. Vite, esbuild and Babel compile one file at a time and never read the .d.ts, so Color.Red stays a property read on an import that doesn't exist:

TypeError: Cannot read properties of undefined (reading 'Red')        (Vitest 4.1)
error TS2748: Cannot access ambient const enums when 'isolatedModules' is enabled.   (tsc)

isolatedModules: true (Next.js projects have it on) is the setting that makes tsc warn you.

4. A module mock deletes it. An enum is a value export. A vi.mock factory that doesn't return it removes it like any other value:

Error: [vitest] No "Role" export is defined on the "./api" mock.

The same happens to an as const object. A union type can't be lost this way — it was erased before the test ran.

The rule

An enum is runtime code, not a type. Tools that only erase types (Node's type stripping, erasableSyntaxOnly) reject it; per-file transpilers can't inline an ambient const enum; and a module mock removes it like any other export.

In a codebase that wants to run under type stripping — or just never think about this again — use a union for the type, plus an as const object when you need the values at runtime:

export const Role = { Admin: "admin", Member: "member" } as const;
export type Role = (typeof Role)[keyof typeof Role]; // "admin" | "member"

That file runs under node --test with plain type stripping. The language side — what an enum compiles to, as const, satisfies, exhaustive checks on a union — is in Narrowing and unions.