第32回：【テストコードのガイドライン その７】【無駄】「if (TEST)」という妥協 ── 汚れたコードにテストの価値はない

♨️ 外部サービスの壁と「名案」

東根温泉支部の開発室。窓の外では、温泉街の街灯が琥珀色の霧の中に点々と浮かび上がり、幻想的な夜が始まろうとしていた。しかし、ヒマリのデスク周辺だけは、決済システムのドキュメントと格闘する彼女の熱気で、冬の寒さを忘れるほどだった。

ヒマリは今、外部の決済APIと連携する重要機能のテストに挑んでいた。前回の「境界線」の教えを胸に、外部サービスへの依存をどう扱うか。それが今の彼女の最大のテーマだ。

ヒマリ： 「うーん……。実際に外部APIを叩いちゃうと、テストのたびに1円ずつ課金が発生しちゃうし、テスト用の決済データが本番の管理画面に溜まっていくのも良くないですよね……。でも、ここを通さないとテストが完了しないし……。」

数分間の沈黙。そして、ヒマリの顔にパッと明るい色が差した。

ヒマリ： 「あ、名案！ テストの時だけ、この処理を『なかったこと』にすればいいんだ！」

ヒマリは迷いなくキーボードを叩き始めた。

♨️プロダクションコードに混ざる「不純物」

翌朝、ヒマリは意気揚々とマリを呼び寄せた。

ヒマリ： 「マリさん、見てください！ 外部APIの壁、突破しました！ 本番コードの中に『もしテスト環境だったら、APIを叩かずに成功を返す』っていう分岐を入れたんです。これで課金を気にせず、テストを何度でも回せるようになりました！」

ヒマリが誇らしげに指し示したコードには、次のような一節が刻まれていた。

def process_payment(self, amount):
    # テスト環境ならAPIを叩かずに成功扱いにする
    if config('APP_ENV') == 'testing':
        return True 

    # 本物の決済API呼び出し
    return PaymentGateway.charge(amount)

マリは、そのコードを数秒間、ただ静かに見つめていた。その沈黙は琥珀色のお茶が冷めていくよりも長く、重かった。

マリ： 「……ヒマリちゃん。そのコードは、本物の挙動をテストしていると言えるのかしら？ ☕」

ヒマリ： 「えっ？ はい、テストはグリーンになりましたし、全体のリズムも良くなりました。何か問題がありましたか？」

♨️ メソッドの切り出しと「身代わり」の技術 ── 鏡を塗るなかれ

マリは静かに椅子を引き、ヒマリの隣に座った。

マリ： 「テストのために本番コードを書き換えるのはね、鏡に映った自分を綺麗に見せるために、自分の顔を洗うのではなく、鏡の方を塗りつぶすようなものよ。☕」

ヒマリ： 「鏡を……塗りつぶす？」

マリ： 「そう。この if(TEST) という分岐がプロダクションコードに混ざった瞬間、そのコードの価値は二つの意味で損なわれてしまうわ。☕」

① それは「テスト」ではない

マリ： 「あなたが書いたテストは、今や if 文の中にある return True を確認しているだけに過ぎないわ。本来呼び出されるべきメソッドが正しい引数で呼ばれているか、戻り値の型が本当に一致しているか。肝心なことは何一つ検証できていないの。これは『テストを通すための妥協』であって、『品質の担保』ではないわ。☕」

② 本番環境への「時限爆弾」

マリ： 「そして何より恐ろしいのは、もし環境設定の判定ミスが起きたり、条件式にバグが紛れ込んだらどうなるか。本番環境で突然『決済をスキップして成功を返す』という大惨事が起きかねない。テストのために、本番を危険に晒す。それは本末転倒だと思わない？ ☕」

ヒマリは血の気が引くのを感じた。良かれと思って入れた「名案」が、実はシステムの信頼性を根底から揺るがす「不純物」だったのだ。

マリ： 「解決策は、コードの中に分岐を書くことじゃない。『外側から身代わりを立てる』 ことよ。☕」

マリはホワイトボードに、決済処理をインターフェース（または抽象クラス）として切り出す図を描いた。

1. インターフェース化: 「決済する」という振る舞いだけを定義する。

2. 本物の実装: 実際にAPIを叩く。本番環境ではこれを使う。

3. 身代わり（モック）: APIを叩いたふりをして、期待する結果を返す。テスト環境ではこれを「注入」する。

♨️ 汚さないことが、信頼への近道

マリの指導を受け、ヒマリは即座に if (env == 'testing') という汚れをコードから削除した。

サキ： 「そうそう。ひま、覚えておきなさい。✨ 本番コードは常に『本物』であるべきなんだ。環境の切り替えはコードの中でコソコソやるんじゃなくて、DIコンテナや環境設定っていう『外側の仕組み』で堂々とやる。それがプロの作法だよ。✨」

サキがいつものように茶目っ気たっぷりにウインクする。

ユイ： 「あぅ……っ。……本番コードが綺麗なままなのに……。テストの時だけ『身代わり』が戦ってくれる。それが、一番安心できるねぇ……っ。」

ユイの言葉に、ヒマリは深く頷いた。

テストコードのためにプロダクションコードに手を加えることは、一見効率的に見えて、実は「設計の敗北」を認めることだったのだ。

ヒマリ： 「テストを通すために魂を売っちゃダメですね……。インターフェースを意識して、本番コードの『純度』を100%に保ちます。どんなに複雑な外部サービスが相手でも、コードを汚さずに制圧してみせます！」

東根温泉の琥珀色の夜風が、窓から入り込み、ヒマリの熱くなった頬を心地よく冷やした。

エディタに並ぶのは、テスト用の不純物が一切ない、凛としたプロダクションコード。

そして、その「純粋な本物」を外側から完璧に支える、洗練されたテストコード。

ヒマリが手に入れたのは、単なるテストの成功ではない。

どんな環境の変化にも揺らがない、システムに対する「絶対的な信頼」という名の、透明な盾だった。

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

テストコードは何のためにあるのでしょうか。 大切なことなので何度でも言いますが、それは「プロダクトコードの品質を担保するため」に他なりません。

品質を担保すべき「盾」であるはずのコードの中に、本番では決して通ることのない、テスト時専用の「逃げ道」を作ってしまうのはどうでしょうか。それはもはや品質を保証しているのではなく、単に「テストの結果を緑色にする」ためだけの、自己満足で無意味な作業に成り下がってしまいます。

実際の現場で、こんな光景を目にしたことがあります。 「テストコードから本番の課金処理を叩くわけにはいかないから」という理由で、課金ロジック全体を if 文で丸ごとスキップし、強制的にテストを成功させていたのです。

……これでは、何の意味もありません。

では、外部サービスが絡むような困難なケースで、どうやって「意味のあるテスト」を書くべきなのか。そこで救世主となるのが、これまで何度もお話ししてきたDI（依存性の注入）です。

課金処理の実装をクラスの内部に固定せず、外部から「注入」できるようにプロダクトコードを設計する。そうすれば、テストの時だけ「決済したふりをして成功（または失敗）を返す」モックと呼ばれる仮の実装を流し込み、本番コードを1行も汚すことなく、完璧な検証が可能になります。

ここで、前回の「staticメソッドはやめましょう」という話も繋がってきます。 staticメソッドを多用し、内部でガチガチに結合してしまったコードは、外部から「身代わり」を注入する隙間がありません。結果としてテストが書けなくなり、安易な if (TEST) という妥協に手を染めることになるのです。

「汚いテスト」は「汚い設計」から生まれます。 本番コードの純度を守り抜く設計の規律こそが、嘘偽りのない、真の品質担保を実現するための唯一の道なのです。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #設計 #DI #依存性の注入 #モッキング #モック #クリーンコード #リファクタリング #ソフトウェア開発 #品質保証 #QA #技術的負債 #プロダクションコード #東根温泉秘密結社 #テスト容易性