【Python】ユニットテストの罠：テスト対象と同じ実装をテストコードに書いてはいけない理由

2025年10月15日

ユニットテストは、コードが期待通りに動作することを保証し、将来のリファクタリングや機能追加に対する「安全網」の役割を果たす、現代の開発に不可欠なプラクティスです。しかし、テストの書き方を誤ると、この安全網は全く機能しない見せかけだけのものになってしまいます。

その中でも特に陥りがちなのが、テスト対象の関数の実装ロジックを、テストコード側でもう一度繰り返してしまうというアンチパターンです。今回は、なぜこのアプローチが危険なのか、そしてどのようにして本当に価値のあるテストを書くべきかを解説します。

問題点：バグを見逃す「自己満足」なテスト

ある文字列を整形し、そのハッシュ値（MD5）を計算する関数 calculate_content_hash をテストするシナリオを考えてみましょう。

main.py

import hashlib

def calculate_content_hash(content: str) -> str:
    """文字列の前後の空白を除去し、UTF-8でエンコードしてMD5ハッシュを返す。"""
    # 注目ポイント： .strip() で前後の空白を除去している
    normalized_content = content.strip()
    
    m = hashlib.md5()
    m.update(normalized_content.encode("utf-8"))
    return m.hexdigest()

この関数に対して、実装ロジックを真似て書いたテストがこちらです。

悪いテストの例 (tests.py):

import hashlib
from main import calculate_content_hash

def test_calculate_content_hash_bad():
    # 入力データ
    input_text = " hello python "
    
    # 実際の関数の実行結果
    actual = calculate_content_hash(input_text)
    
    # --- 問題の部分：テスト側でも同じロジックを再実装してしまっている ---
    # テストを書いた開発者が「空白は除去されるはず」と考えて、手動で除去した文字列を使う
    expected_content = "hello python" 
    
    m_expected = hashlib.md5()
    m_expected.update(expected_content.encode("utf-8"))
    expected = m_expected.hexdigest()
    # ----------------------------------------------------------------

    assert actual == expected

このテストは成功します（assertは通ります）。しかし、このテストにはほとんど価値がありません。なぜなら、もし calculate_content_hash の .strip() の実装が間違っていたとしても、テストを書いた開発者が同じ思い込みでテストを書けば、間違いに気づくことができないからです。

例えば、calculate_content_hashの実装が誤ってcontent.lstrip()（左側の空白しか除去しない）になっていたとします。このテストはそれでも成功してしまいます。これは、テストが「実装が正しいこと」を検証しているのではなく、「実装とテストのロジ- ックが一致していること」しか検証していないためです。これはバグを見逃す「緑色の嘘（The Green Lie）」とも呼ばれる危険な状態です。

解決策：既知の「正しい答え」と比較する

信頼できるテストとは、実装の詳細から独立した**「仕様」を検証するものです。つまり、「ある入力に対して、どのような出力が返ってくるべきか」という不変の正解**と比較します。

この「正解」は、事前に一度だけ、信頼できる方法（例えば、Pythonのインタラクティブシェルや外部ツールなど）で計算し、テストコード内に**静的な値（リテラル）**としてハードコードします。

良いテストの例 (tests.py):

from main import calculate_content_hash

def test_calculate_content_hash_good():
    # 入力データ
    input_text = " hello python "
    
    # 期待される結果（事前に計算済みの「正しい答え」）
    expected_hash = "d80a8f837c3c528c68881b85f03a651a"
    
    # 実際の関数の実行結果
    actual = calculate_content_hash(input_text)
    
    # 実装ロジックから独立した「正しい答え」と比較する
    assert actual == expected_hash

このテストは、calculate_content_hashの内部実装がどうであれ、「 " hello python " という入力を与えられたら、必ず "d80a8f...651a" という出力を返さなければならない」という明確な仕様を検証しています。

このアプローチの利点は以下の通りです。

独立した検証: テストは実装の詳細から独立しており、真の「第三者」として機能します。
リファクタリングへの耐性: 将来、calculate_content_hashの内部実装をより効率的な方法に変更しても、出力される仕様（ハッシュ値）が変わらない限り、テストを修正する必要はありません。
強力なリグレッション防止: もし誰かが意図せずロジックを変更し、結果が変わってしまった場合、このテストは即座に失敗し、バグの混入（リグレッション）を防ぎます。

`pytest.mark.parametrize`でさらに堅牢に

pytestのようなモダンなテストフレームワークを使えば、複数の入力と期待される出力のペアに対して、同じテストを効率的に実行できます。

import pytest
from main import calculate_content_hash

@pytest.mark.parametrize(
    "input_text, expected_hash",
    [
        (" hello python ", "d80a8f837c3c528c68881b85f03a651a"), # 空白あり
        ("hello python", "d80a8f837c3c528c68881b85f03a651a"),   # 空白なし
        ("Python", "98a722652asha7928238as98c7343212"),     # 別の入力
        ("", "d41d8cd98f00b204e9800998ecf8427e"),             # 空文字
    ]
)
def test_calculate_content_hash_multiple(input_text, expected_hash):
    assert calculate_content_hash(input_text) == expected_hash