実装の変更に振り回されないこと - ユニットテスト（単体テスト）の考え方

「実装の内部構造を変えただけでテストが壊れる」状態は、リファクタリングを躊躇させるので、テストがあることが逆に開発の足枷になります。

学習者

リファクタしただけでテストが赤くなる…。これってテストが悪いの？それともコードが悪いの？

テストの偽陽性とは

テストの偽陽性とは、テストが失敗したが、実際にはバグがないことを意味します。

偽陽性が少ないことは、リファクタリングの耐性を高めることにつながります。

逆に、偽陽性が多いテストは、失敗しても「またテストが壊れただけかもしれない」と思われるようになります。

テストの価値は、赤くなったときに開発者がすぐ反応できることです。失敗の信頼性が落ちると、テストは警報として機能しなくなります。

偽陽性でテストの意味がなくなってしまう

開発でコードを記述していて、問題あるコードを事前に検知できることがテストの意味ですが、偽陽性が多いと、その信頼性が失われてしまいます。

テストの偽陽性を減らす方法

最終的な結果を確認することで、偽陽性を減らすことができます。

テストが確認すべきなのは「外部から観測できるもの」です。これは大きく3つあります。

戻り値
状態の変化（DBに保存された、オブジェクトのプロパティが変わった等）
外部への呼び出し

区別の基準はシンプルで、「その検証対象を変えたとき、ユーザーや外部システムが気づくか」です。

気づくなら振る舞い、気づかないなら実装の詳細です。

偽陽性を生みやすいテストの例

次のテストは、ユーザー名を正規化する処理を確認しているように見えます。

it('ユーザー名を正規化する', () => {
  const normalizer = vi.fn((name: string) => name.trim().toLowerCase());
  const service = new UserService(normalizer);
 
  service.createUser(' Alice ');
 
  expect(normalizer).toHaveBeenCalledWith(' Alice ');
});

typescript

このテストは、normalizer が呼ばれたことを確認しています。

しかし、ユーザーから見て重要なのは「保存されたユーザー名が alice になっていること」です。内部で normalizer を呼ぶかどうかは実装の詳細です。

次のように、観測できる結果を見る方がリファクタリングに強くなります。

it('ユーザー名の前後の空白を取り除き、小文字で保存する', () => {
  const repository = new InMemoryUserRepository();
  const service = new UserService(repository);
 
  service.createUser(' Alice ');
 
  expect(repository.findByName('alice')).toEqual({
    name: 'alice',
  });
});