第28回：【テストコードのガイドライン その3】テストに「分岐」はいらない ── 迷いのあるテストはバグを生む

♨️ ヒマリの「万能」テストコード

東根温泉支部の開発室。窓からは温泉街を包む夕霧がうっすらと見え、どこからか硫黄の香りが微かに漂ってくる。そんな穏やかな空気とは裏腹に、ヒマリは鼻歌混じりに、かつてないほどのスピードでキーボードを叩いていた。

前回学んだ「AAAの規律」を武器に、ヒマリのテストコードは劇的に読みやすくなったはずだった。しかし、効率を追求する彼女の探究心は、さらなる「高み」を目指していた。

ヒマリ： 「……できた！ これですよ、これ。究極の効率化！」

サキ： 「おっ、ひま。何そのドヤ顔。✨ また新しい武器でも開発したの？✨」

ヒマリ： 「サキ先輩、見てください！ 正常系も異常系も、これ一発で判定できる『万能テストメソッド』です！ 今まではパターンごとにメソッドを分けてましたけど、それだとコードが長くなるじゃないですか。だから、ステータスがAならこの期待値、Bならこっちの例外、空っぽならエラーを出す……っていう風に、if 文でスマートに分岐させたんです！」

ヒマリがモニターを指し示す。そこには、テストコードの中に立派な条件分岐の森が築かれていた。

サキ： 「んー、スマートっていうか……。ひま、それ、テストコードの中に『迷い』が見えるよ？✨」

♨️ テストコードが牙を剥く ── 自作自演の迷宮

サキの忠告が現実になるのに、時間はかからなかった。 翌朝、CI（継続的インテグレーション）の結果を見たヒマリの悲鳴が開発室に響き渡った。

ヒマリ： 「ええっ！？ なんで！？ 昨日まで通っていたテストが全部真っ赤になってる……。でも、プロダクションコードは1行も触ってないのに！」

慌ててデバッグを始めるヒマリ。しかし、プロダクション側のロジックをどれだけ追っても、バグは見当たらない。不審に思ったルルが、ヒマリの背後にスッと立つ。

ルル： 「（眉間に深い皺を寄せて）……ヒマリさん。プロダクションコードを疑う前に、自分の書いたその『賢すぎるテスト』を疑いなさい。……。ほら、ここッ！😤」

ルルが画面上のテストコードの一行を指差す。

ルル： 「テスト内の if 文の条件式そのものが間違っていますッ！ 正常系のルートを通るべきデータなのに、テストコード側のロジックが勝手に異常系だと判定して、誤ったアサーションを叩いています。……プロダクションコードは正しいのに、テストコードを成功させるために、テストコードをデバッグする。これほど無意味で、滑稽な時間はありませんッ！！😤」

ヒマリ： 「テ、テストコードをデバッグ……。私が書いた『正しさを証明するはずのコード』に、バグが紛れ込んでいたなんて……。」

テストコードにロジック（if や for）を持ち込むということは、そのテスト自体の正当性を担保するための「テストのテスト」が必要になるという、終わりのない泥沼に足を踏み入れることを意味していた。

♨️ 原則、テストにロジックはいらない ── 「一直線」の美学

ショックで項垂れるヒマリを、マリが静かにラウンジへと誘う。淹れたてのコーヒーから立ち上る湯気が、ヒマリの焦燥を少しずつ溶かしていく。

マリ： 「ヒマリちゃん。テストコードには、プロダクションコードとは正反対の美学が求められるのよ。……。それはね、『一直線の美学』よ。☕」

ヒマリ： 「一直線……。曲がっちゃいけない、っていうことですか？」

マリ： 「そう。『テストコードは、計算をしてはいけない』。これが鉄則なの。☕」

マリは手元のメモ帳に、二つの対比を描いた。

【プロダクションコード】 動的に変化する。複雑な条件を捌き、計算を行い、答えを導き出す「脳」の役割。

【テストコード】 静的な事実である。入力と出力を1対1で結びつけ、ただそこに「あるべき姿」を並べるだけの「定規」の役割。

マリ： 「計算機を校正するための定規が、それ自体で計算を始めたら、何を信じればいいかわからなくなるでしょう？ 複雑なロジックをテストの中で再現しようとしてはいけないわ。テストは、『Aを入力したらBが出る』という静的な事実の羅列であるべきなの。☕」

例えば、100個のデータに対して同じ検証を行いたいとする。 ヒマリは for ループを回して、ループの中で if を使ってアサーションを切り替えようとした。しかし、規律あるプロの世界では、それを「パラメタライズドテスト」などの宣言的な手法で、100個のケースをただ「並べる」だけに留める。

サキ： 「100回のループの中で頭を使うより、100個の事実を無心に並べるほうが、遥かに『純度』が高いんだよ。テストは賢くなくていい。むしろ、世界で一番『愚直』であるべきなんだ。✨」

♨️ 分岐するなら、テストを分けよ

マリとサキの教えを受け、ヒマリは自分の「万能テスト」を解体し始めた。

ルル： 「ヒマリさん、覚えておきなさい。条件分岐が必要だと思った瞬間、それは『別のテストメソッド』に分けるべきサインですッ！😤」

ヒマリ： 「……わかりました。ステータスAのテスト、ステータスBのテスト、空の場合のテスト。それぞれに名前をつけて、別々のメソッドとして定義します。」

ヒマリが書き直したテストコードは、もはや「万能」ではなかった。 しかし、その代わりに圧倒的な「透明度」を手に入れていた。

• test_calculate_total_price_success_case

• test_calculate_total_price_invalid_status_error

• test_calculate_total_price_empty_data_exception

テスト名に「〜の場合」と理由が明記され、その中身は上から下まで一行の迷いもなく流れている。

ユイ： 「あぅ……っ。……これなら、もし失敗しても、どのパターンの、どのアサーションがダメだったのか……一瞬でわかるねぇ……っ。」

ユイの言葉に、ヒマリは深く頷いた。 これまでは「失敗した」という通知を受けてから、テストコードの中のどの if 文を通ったのかを追いかける必要があった。しかし今は、失敗したメソッド名を見ただけで、システムのどの仕様が壊れたのかが即座に理解できる。

ヒマリ： 「設計の敗北を、テストコードのロジックで誤魔化しちゃダメなんですね。テストが一直線に書けないなら、それは私の設計がまだ複雑すぎるか、単にサボろうとしているだけ。……迷ったら分ける。これからは『愚直な盾』を作ります！」

東根温泉の琥珀色の湯に浸かるように、ヒマリの心はスッキリと晴れ渡っていた。 「一直線」に伸びるテストコードは、そのまま彼女が歩むべきエンジニアとしての真っ直ぐな道を示しているようだった。

📜 ボスの秘蔵：設計の美学と現場のリアル

そもそも「ロジック」とは何でしょうか。

テストコードの中に、値を判定するための if 文や、繰り返し処理のための for 文が含まれているとき。それはテストコードの中に「ロジック」が紛れ込んだ瞬間です。

前回のAAAでも触れましたが、テストコードはプロダクトコードの品質を担保するために存在します。しかし、もしテストコードの中にロジックを含めてしまったら、どうなるでしょうか。私たちは、そのテストコードが「正しく動いているか」を確かめるために、また別の「テストのテスト」を書かなければならなくなります。

本来、品質を守るための定規であるはずのテストコードが、その精度を疑われ、矛盾の渦に飲み込まれていく……。これほど不毛なことはありません。

「でも、ロジックを使わずに真面目に書こうとすると、何度も同じようなコードを書くことになってしまう……」

そう嘆いているプログラマも多いはずです。しかし、そこで安易に for ループに逃げてはいけません。私たちが使うべき正解は、ロジックで固めることではなく、「データプロバイダー（DataProvider）」という仕組みを活用することです。

データプロバイダーを使えば、テストの「手順（ロジック）」はそのままに、与える「入力値」と「期待される結果」だけを外部から注入することができます。

特に境界値チェックを行う際、この手法は絶大な威力を発揮します。

• 境界値を超える直前のデータ

• 境界値ぴったりのデータ

• 境界値を超えた直後のデータ

• まったく関係のない不正なデータ

これらを一つのテーブル（表）のように定義し、テストメソッドに流し込む。 テストの中身は常に「一直線」のままで、検証のバリエーションだけを劇的に増やすことができるのです。

こうして書かれたテストは、何より「読み手」に優しい。 「このテストは、どんなパターンのデータを検証しようとしているのか」が一目で理解でき、そこに書き手の迷いや、テスト自体のバグが入り込む隙はありません。

「楽をするためにロジックを書く」のではなく、「意図を伝えるためにデータを並べる」。 この発想の転換こそが、テストコードの純度を高めるための鍵なのです。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #コードの品質 #リファクタリング #クリーンコード #ソフトウェア開発 #設計 #QA #バグ修正 #パラメタライズドテスト #東根温泉秘密結社 #可読性 #エンジニアの日常