第25回：【テストコードのガイドライン 序章】私たちが「盾」に込める7つの約束

♨️ 設計の「攻め」と、テストの「守り」

東根温泉支部のラウンジ。窓の外では、さくらんぼの白い花が春の風に揺れている。ヒマリは、前シリーズで学んだ「設計の作法」を思い返しながら、自分の書いたコードを眺めていた。

依存性の注入（DI）、単一責任の原則、インターフェースの活用……。かつての混沌としたコードは影を潜め、今は整然としたクラス図が脳内に描けるほどになっている。しかし、ヒマリの表情は晴れない。

ヒマリ： 「……設計の大切さは、身に染みてわかりました。でも、これを『壊さないように守り続ける』自信が、まだ持てなくて。今の私のテストコード、なんだか継ぎはぎだらけなんです。」

マリ： 「いい気づきね、ヒマリちゃん。☕」

マリが琥珀色の温泉成分を含んだお茶を差し出しながら、優しく微笑む。

マリ： 「設計が未来を切り拓く『攻め』の技術なら、テストはその歩みを確かなものにする『守り』の技術。この二つが揃って初めて、システムは真に安定した命を宿すのよ。……これまで、私たちが現場で血を流しながら守り抜いてきた『テストの作法』。その目次を、今ここであなたに伝承しようと思うわ。」

♨️ 秘密結社に伝わる「7つのガイドライン」

ルルが、秘密結社の奥義が記された黒板をバシッと叩く。そこには、これから学ぶべき「7つの規律」が、重々しく刻まれていた。

ルル： 「ヒマリさん！ これからあなたが学ぶ、テストコードを書く際の 『7つのガイドライン』 ですッ！！ これを魂に刻みなさいッ！！😤」

1. プログラマから顧客のものへ

「自分が書いたコードが動くか不安だから確認する」……それは自分へのメモに過ぎません。私たちが目指すのは、顧客に対して「このシステムは仕様通りに動くことを、機械が永久に保証し続ける」という物理的な契約書です。テストの持ち主を「自分」から「顧客」へと再定義することから、すべては始まります。

2. むやみなアサーションの禁止

「1行書くたびにアサーションで確認する」……それは自信のなさの表れです。処理の途中で実況中継をするようなテストは、ノイズでしかありません。最後の一撃で「最終的な結果」を鮮やかに検品する。そんな「型」を身につける必要があります。

3. テストコードにロジックは不要

テストの中に if や for を持ち込んだ瞬間、そのテスト自体の「正しさ」を誰が保証するのかという泥沼に陥ります。テストは計算をしてはいけない。常に、迷いのない「一直線」であるべきなのです。

4. 実行時間は短いほど良い

「40分かかるテストは死」と同義です。実行が遅いテストを、開発者はやがて実行しなくなり、テストは「負債」に変わります。1秒でも早く結果を出す。そのスピードこそが、開発者の創造性を守る心拍（フィードバック）となります。

5. 意味のあるテストコードを書こう

カバレッジを通すためだけの「空っぽなテスト」に価値はありません。形式的な網羅ではなく、「このコードで何を壊したくないか」という設計者の意図を込めること。それが、生きたテストコードの条件です。

6. staticメソッドとプロセス分離の回避

staticメソッドは、テストの自由を奪うガチガチに固まった「呪い」です。実行プロセスを分けないとテストできないようなコードは、設計の敗北と言えます。DI（依存性の注入）を駆使して、しなやかで高速なテスト環境を構築しましょう。

7. カバレッジ100％は目指さない

数字は人を狂わせます。100％という数字に安心するために、本番コードを歪ませたり、無意味なテストを量産するのは本末転倒な「数字への亡者」です。80%の魂がこもったテストは、100%のゴミテストより遥かに価値があります。

♨️ 規律がもたらす「本当の自由」

あまりに厳しい規律に圧倒され、ヒマリは小さく肩を落とした。「自由がない……」と。しかし、サキが軽快に、かつ真剣なトーンでフォローを入れる。

サキ： 「ひま、これさ、一見不自由に見えるけど、実は逆なんだよ。✨」

サキは窓の外の広大な温泉街を指差した。

サキ： 「この規律があるからこそ、AIにコードを書かせても、人間がパッと見た瞬間に『これ、正しいわ』って判断できる。規律がないAIコードは、レビューするだけで一生が終わっちゃう。……規律こそが、AI時代に私たちが自由でいるための、最強の武器なんだよ！✨」

マリ： 「さあ、ヒマリちゃん。明日から一つずつ、この規律を噛み砕いて教えてあげるわね。☕」

ヒマリ： 「……はい！ 私、自分のためのテストを卒業して、本当の『盾』を作れるようになります！」

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

設計の作法に関するお話がひと段落しましたので、今回から「そもそも、なぜ設計の話が必要なのか？」という本質に迫る連載を始めます。

私が「設計が大事だ」と言い続ける最大の理由は、それが「テストコードの品質」と不可分に紐づいているからだと考えています。

昨今、生成AIを使ってテストコードを爆速で生成させることも容易になりました。しかし、AIが作成するテストコードの多くは、単に「エラーが出ずに動くもの」であって、設計者の意図を汲み取った「意味のあるテスト」ではないことが多々あります。

特に、カバレッジを100％にしてほしいという安易な指示を出してしまうケースには、大きな罠が潜んでいます。AIは「網羅率」という数字を達成することだけを目的に、極めて脆弱なコードを出力するからです。プロダクトコードのロジックを書き換えても、テスト側を一切修正せずにパスしてしまう……そんな「魂の抜けたテストコード」が、果たして現場の盾になり得るでしょうか。

それは、本当に私たちが、そしてお客様が必要としているテストコードでしょうか？

テストコードは、設計の合わせ鏡です。 良い設計はテストを容易にし、良いテストは設計の正しさを証明し続けます。 これから全10回にわたり、AI時代だからこそ立ち返るべき「テストの原点」を掘り下げていきたいと思います。

琥珀色の湯に浸かるような気持ちで、ゆっくりとお付き合いいただければ幸いです。

（つづく）

#エンジニア #プログラミング #設計 #テストコード #ユニットテスト #TDD #ソフトウェア開発 #生成AI #AI活用 #Python #PHP #東根温泉秘密結社 #ボスの秘蔵 #品質保証 #リファクタリング #駆け出しエンジニアと繋がりたい #DX