時々落ちるテストには、書かれていない入力がある

9時〜18時を営業中と判定する関数と、そのテストです。

// shop.mjs
export function isOpen(now = new Date()) {
  const h = now.getHours();          // 実行した機械のタイムゾーンでの「時」
  return h >= 9 && h < 18;           // 9時〜18時が営業時間
}

// clock.test.mjs(抜粋)
test("営業中なら注文を受け付ける", () => {
  console.log("TZ=", process.env.TZ, "local hour=", new Date().getHours(), "ISO=", new Date().toISOString());
  assert.equal(isOpen(), true);
});

同じコードを TZ だけ変えて2回ずつ走らせました(node v24.21.0、macOS)。

### TZ=Asia/Tokyo
TZ= Asia/Tokyo local hour= 9 ISO= 2026-09-24T00:04:59.172Z
✔ 営業中なら注文を受け付ける (1.119792ms)
exit=0
### TZ=Europe/London
TZ= Europe/London local hour= 1 ISO= 2026-09-24T00:04:59.232Z
✖ 営業中なら注文を受け付ける (1.648084ms)
exit=1
### TZ=Asia/Tokyo
TZ= Asia/Tokyo local hour= 9 ISO= 2026-09-24T00:04:59.293Z
✔ 営業中なら注文を受け付ける (0.998125ms)
exit=0
### TZ=Europe/London
TZ= Europe/London local hour= 1 ISO= 2026-09-24T00:04:59.353Z
✖ 営業中なら注文を受け付ける (1.339375ms)
exit=1

ISO 時刻はほぼ同じ瞬間です。東京では local hour= 9 で緑、ロンドンでは local hour= 1 で赤。結果を決めていたのは、テストのどこにも書かれていない「いつ、どこの機械で走らせたか」でした。Luo らの論文は Time の分類で a test may fail when the midnight changes in the UTC time zone と書きます。論文の例は UTC の日付の変わり目、この実演は現地の「時」で別物ですが、どちらもシステム時刻という書かれていない入力です。ただし論文で Time に分類されたのは161件中5件と少数で、この例は分かりやすさで選んでいます。

では時計を固定すれば済むか。MockTimers で「今」を 2026-09-24T03:00:00Z に固定した版と、さらに process.env.TZ = "Asia/Tokyo" も固定した版です。

### $ TZ=Asia/Tokyo node --test clock-mocked.test.mjs
TZ= Asia/Tokyo local hour= 12 ISO= 2026-09-24T03:00:00.000Z
✔ 営業中なら注文を受け付ける(時計を固定) (1.196084ms)
### $ TZ=Europe/London node --test clock-mocked.test.mjs
TZ= Europe/London local hour= 4 ISO= 2026-09-24T03:00:00.000Z
✖ 営業中なら注文を受け付ける(時計を固定) (1.598083ms)
### $ TZ=Europe/London node --test clock-pinned.test.mjs
TZ= Asia/Tokyo local hour= 12 ISO= 2026-09-24T03:00:00.000Z
✔ 営業中なら注文を受け付ける(時計とタイムゾーンを固定) (0.823459ms)

時計を固定しても、ロンドンでは local hour= 4 で赤のままです。MockTimers が固定するのは「どの瞬間か」までで、その瞬間を何時と読むかはタイムゾーンが決めます。タイムゾーンも固定した版は、東京・ロンドン2回ずつの4回とも緑でした(上は抜粋)。書かれていない入力は、1つとは限りません。

序章『生成されたコードの読み方 — 「動く」と「正しい」の差』の対比例に、setTimeout(init, 100) で包んで「動くようになりました」と返す場面がありました。同じ形のテストです。

// loader.mjs: かかる時間は機械の混み具合で変わる(ここでは 0〜150ms の乱数で代用)
export function startLoader(state, delay = Math.random() * 150) {
  setTimeout(() => { state.ready = true; }, delay);
}

// wait.test.mjs(抜粋): 100ms 待ってから確かめる
startLoader(state);
await sleep(100);
assert.equal(state.ready, true);

// wait-mocked.test.mjs(抜粋): 偽の時計を進める
t.mock.timers.enable({ apis: ["setTimeout"] });
startLoader(state, 150);        // 最悪の遅さを入力として明示
t.mock.timers.tick(149);
assert.equal(state.ready, false);
t.mock.timers.tick(1);
assert.equal(state.ready, true);

wait.test.mjs: 30回中 pass=21 fail=9  並び=PFPPPFFPFFPPFPPPFPPPFPPPPPPPFP
wait-mocked.test.mjs: 30回中 pass=30 fail=0  並び=PPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
wait.test.mjs: 30回中 pass=19 fail=11  並び=PPPPPFPFPPPFPPPFFPPFPFPPFPFFPF
wait-mocked.test.mjs: 30回中 pass=30 fail=0  並び=PPPPPPPPPPPPPPPPPPPPPPPPPPPPPP

遅れは0〜150msの一様乱数なので、100ms を超えて落ちる確率は約3分の1、30回なら約10回です。実測は9回と11回でした。コードは1文字も変わっていません。乱数は機械の混み具合の代用で、本物の遅れが乱数だという意味ではありません。

MockTimers 版は、待ち時間を「150ms」とテストに書き、時計をテストが進めます。書かれていなかった入力を、書かれた入力に変えたから、60回とも緑です。

待ち時間を延ばす直し方はどうでしょう。Luo らの Table 4 では、sleep の追加・変更による修正20件のうち、flaky を完全に除いたものは0件、減らしただけが20件でした。