第30回：【テストコードのガイドライン その5】どこまでテストするか？ ── フレームワークを「信じる」勇気

♨️ DB接続の壁にぶつかるヒマリ

東根温泉支部の開発室。窓の外には、静かに雨に濡れる温泉街が広がっている。しっとりと落ち着いた外の空気とは対照的に、開発室の一角では、ヒマリが唸り声を上げながらモニターと格闘していた。

前回の連載で「テストの速度こそが命」であることを学んだヒマリ。彼女は今、自作のユーザー登録機能を高速に検証するためのテストコードを書こうとしていた。しかし、その作業は1時間前から一歩も前に進んでいない。

ヒマリ： 「うーん……。保存処理のテストを書かなきゃいけないのに、どうしてもテスト用のDB設定がうまくいかない……。ドライバがないとか、接続が拒否されたとか、エラーばかり出ちゃうんです。」

ヒマリのモニターには、コードそのもののバグではなく、インフラ設定に起因する無機質なエラーメッセージが並んでいた。

サキ： 「おー、ひま。また何かに取り憑かれたような顔してるね。✨ 画面がエラーで真っ赤っかじゃん。何に苦戦してるの？✨」

サキが、淹れたてのハーブティーを片手に覗き込んできた。

ヒマリ： 「あ、サキ先輩……。ユーザー情報をDBに保存する処理のテストを書こうとしてるんですけど、テスト環境のDBが立ち上がらなくて。これを解決しないと、テストが1ミリも進まないんです。保存ボタンを押して、ちゃんとテーブルに1件増えたかどうかを確認したいだけなのに……。」

♨️ テストのためにDBが必要という「固定観念」

サキは、ヒマリが必死に格闘している「DB接続設定」のファイルを見て、小さく息を吐いた。

サキ： 「なるほどねー。DBね。……。でもさ、ひま。そもそも論として、そのテストを書くのに、本当に『本物のDB』が必要なのかな？✨」

ヒマリ： 「えっ？ だって先輩、DB保存の機能をテストするんですよ？ 当然、本物のDB（あるいはテスト用のDB）に接続して、実際にデータが入ったことをSQLで見に行かないと、『成功しました』って言えない気がして……。」

ヒマリの目には、迷いがない。プログラミングとは、入力したものが最終的な場所に届くことを確認する作業だ。DB保存のテストなら、DBを確認する。それは彼女にとって、疑いようのない「正論」だった。

サキ： 「うん、気持ちはわかるよ。でもそれって、実は『君のロジック』のテストじゃなくて、ただの『DBの接続確認』になっちゃってない？✨」

サキは空いているホワイトボードの前に立ち、マーカーを手にした。

♨️ メソッドの見直しと「責務」の分離

サキ： 「ひま、君が書いた保存メソッドの構造を、ざっくり書き出してみるよ。✨」

サキがボードに書いたのは、多くの開発者が無意識に書いている、標準的な「保存処理」の構造だった。

def register_user(self, name, email):
    # 1. 保存用のエンティティ（モデル）を組み立てる
    user = User(name=name, email=email)
    user.status = "ACTIVE"
    user.created_at = now()

    # 2. フレームワークの機能を使ってDBに保存する
    user.save()  # ← ここ！

サキ： 「このメソッド、大きく分けて2つのフェーズがあるでしょ？✨ ひとつは『保存するためのデータを正しく準備する』ロジック。もうひとつは『準備したデータをDBへ流し込む』処理。……。後者の user.save() って、誰が作ったコード？」

ヒマリ： 「え……それは、私たちが使っているWebフレームワークのライブラリですけど。」

サキ： 「そうだよね。その save() メソッドは、世界中の何万人、何十万人という開発者が毎日使い倒して、24時間365日テストされ続けている、最強に枯れたコードなんだよ。✨ ……。それを、今さら君のローカル環境で『本当に保存されるかな？』ってテストして、時間を溶かす必要、本当にある？✨」

サキの言葉に、ヒマリはハッとした。

サキ： 「君がテストで保証しなきゃいけないのは、『save()を呼ぶ直前のデータが、仕様通りに作られているか』という君自身のロジックだけなんだよ。DBにビットが書き込まれるかどうかは、フレームワークとDB製品の責任。君の責任じゃない。そこを『信じる』勇気を持たないと、テストはいつまで経っても軽くならないんだよ！✨」

♨️ フレームワークとの「境界線」を引く ── 集中すべき場所

サキの指摘を受け、マリが静かに補足を入れる。彼女の手には、琥珀色の温泉水で淹れたお茶が握られている。

マリ： 「ヒマリちゃん。これが前回言った『設計とテストの繋がり』の正体の一つよ。☕」

ヒマリ： 「設計と……繋がり……？」

マリ： 「そう。DB保存そのもの（インフラ）と、保存する内容を決めること（ドメインロジック）を、頭の中で切り分けるの。そうすれば、テストは驚くほどシンプルになるわ。☕」

マリはホワイトボードの図に、一本の太い線を引いた。

マリ： 「DBに正しく保存されるかどうかは、フレームワークの責務。保存すべきデータが、ビジネスルールに則って正しく作られているか。これが、私たちが命を懸けて書くべきロジックの責務なのよ。☕」

もしこの境界線を引くことができれば、テストの際にわざわざ本物のDBを立ち上げる必要はなくなる。モックやスタブを使って「保存したことにする」だけで、肝心のロジック部分はインメモリで、ミリ秒単位の速さで検証できるのだ。

ユイ： 「あぅ……っ。……フレームワークを『信じる』ことで……私たちは、自分たちが書いた一番大事なロジックだけに集中できるんだねぇ……っ。それはまるで、信頼できるパートナーに背中を預けて、目の前の敵に集中する騎士みたいだねぇ……っ。」

ユイの詩的な表現に、ヒマリの迷いは完全に消えていた。 自分ですべてを抱え込み、他人の書いたコードの正当性まで自分で証明しようとしていた傲慢さと、それゆえの不自由さ。

ヒマリ： 「何でもかんでも、テーブルの最後まで追いかけちゃダメなんですね。フレームワークとの境界線を引く。それが、テストを軽くし、なおかつ『何を保証しているか』を明確にするコツなんですね……！」

ヒマリは再びエディタに向かった。 今度はDB設定ファイルではなく、ロジックを抽出し、テストしやすい形にリファクタリングするためのコードを書き始めた。

窓の外では、いつの間にか雨が上がり、雲の間から柔らかな光が温泉街を照らし始めていた。 境界線を引くことで手に入れた「自由」。ヒマリの書くテストコードは、もはや重い鎖に繋がれたものではなく、ロジックの正しさを鮮やかに証明する、軽やかな盾へと進化していた。

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

「意味のあるテストコードを書く」。 そう言葉で理解したつもりになっても、いざエディタに向かうと、その線引きは非常に難しいものです。

今回は「フレームワークの機能は、フレームワーク側のテストに任せるべきだ」という話をしましたが、これはフレームワークに限った話ではありません。あらゆる「外部環境」との向き合い方に通じる思想です。

例えば、PHPやPythonからシェルを叩く処理を実装したとします。 もし、開発環境と本番環境でシェルのバージョンが異なっていたらどうでしょう。（本来あってはならないことですが、現実の現場では起こり得る話です） 本番環境では正しく動くシェルが、開発環境では「似ているが微妙に挙動が違う」という状況。この時、テストコードはどこまでを担保すべきでしょうか。

シェルを叩き、その結果が正しいかどうかを検証するテストを書きたくなる気持ちはわかります。しかし、その「正しさ」は本番環境で動かさない限り、本当の意味では確定しません。開発環境でどれだけ「本番に近い動き」をする代用品を用意してテストしたところで、それが本番での成功を100%保証することはないのです。

これを、野球に例えてみましょう。 メジャーリーグで活躍する大谷翔平選手のボールを打つことが、最終的なミッションだとします。その練習（テスト）のために、かつての名投手、野茂英雄さんに渾身のストレートを投げてもらったとしましょう。

仮に野茂さんのボールを完璧に打てたとしても、それは「大谷翔平のボールを打つ」という要件をクリアしたことにはなりません。野茂さんのボールを打てるフォームが、大谷さんの160km超の速球やスイーパーに対応できる保証はないからです。

であれば、無理に「誰か（外部環境）」をマウンドに立たせて、その場限りの結果を追うよりも、「自分のバッティングフォームが、理想的な軌道を描けているか」という『ふるまい』そのものをチェックする方が、遥かに有意義だと思いませんか？

もちろん、野茂英雄のボールを打てる能力があれば、大谷翔平のボールも打てる可能性は高いでしょう。しかし、私たちがテストコードで検証したいのは、個人の「地頭の良さ」や「性能」ではなく、システムとしての「正しいふるまい」です。

環境に依存する「結果」を追いかけるのではなく、環境を切り離した状態で、自分たちのロジックが「正しく意図を伝えられているか」を検証する。 この「ふるまいのテスト」へのシフトこそが、外部環境に左右されない、真に堅牢な盾を作るための極意なのです。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #ソフトウェア開発 #設計 #フレームワーク #モック #スタブ #リファクタリング #クリーンコード #DBテスト #開発効率 #東根温泉秘密結社 #技術的負債 #境界線 #関心の分離