第29回：【テストコードのガイドライン その4】40分のテストは「死」と同義 ── スピードこそがテストの命

♨️ 順調な開発の裏に潜む「影」

東根温泉支部の窓からは、温泉街に立ち上る湯気が夕日に染まり、幻想的な琥珀色を湛えているのが見える。開発室の中は、ヒマリの快調なキーボードの音だけが、心地よいリズムを刻んでいた。

ヒマリはここ数日、新しい大規模機能のテスト実装に没頭していた。前回学んだ「一直線の美学」を守り、分岐のない純度の高いテストを積み上げている。その表情には、一つの大きな仕事をやり遂げようとする充実感が漂っていた。

サキ： 「おー、ひま！ 調子よさそうじゃん。✨ テスト、順調に進んでる？ そろそろ次のメイン機能、こっちのブランチに合流できそうかな？✨」

サキが、いつもの軽い足取りでヒマリのデスクにやってくる。

ヒマリ： 「あ、サキ先輩！ ちょうど今、最後のテストケースを書き終えたところです。今まさに、手元のローカル環境で全テストを回し始めました。これが通れば完了です！」

サキ： 「おっけー、さすが。じゃあ結果が出たら教えて。終わったら一緒に、あそこの新しい足湯にでも行こうよ。✨」

サキは軽く手を振って、自分のデスクへと戻っていった。

♨️ 終わらない10分間、そして「40分」の宣告

10分後。サキが再びヒマリの席を訪れる。

サキ： 「終わった？✨ ささっとマージしちゃおうよ。」

ヒマリ： 「……。いえ……すみません、まだです。今、ちょうど半分を過ぎたあたりで……。」

ヒマリのモニターには、ターミナル上で一つずつ、ゆっくりとドットが表示されていくテストの進捗画面が映し出されていた。一つのドットが出るまでに、数秒、時には十数秒の沈黙がある。

サキ： 「え、まだ？ 10分経ったよ？ 結構ケース数多いの？✨」

ヒマリ： 「いえ、ケース数自体はそこまでではないんですけど……。1ケースごとに、ちょっと時間がかかっているみたいで……。」

サキの表情から、いつもの余裕が少しずつ消えていく。さらに時間が経過する。開発室の時計の針が、非情にも進んでいく。

サキ： 「……ねぇ、ひま。これ、もしかして全部終わるまでどのくらいかかるの？✨」

ヒマリ： 「ええと……このペースだと……残りも合わせて、全部で40分くらいですかね……。」

サキは一瞬、言葉を失った。「40分」。それは開発の現場において、単なる待ち時間以上の重みを持つ数字だった。

♨️ テストが「開発」を殺している ── フィードバックの断絶

ルル： 「（机をバンッ！と叩いて、背後から雷を落とす）……ヒマリさんッ！ 『40分かかるテストコードはだめ』 ですッ！！😤」

ルルの怒鳴り声に、ヒマリは椅子から飛び上がらんばかりに驚いた。

ヒマリ： 「ル、ルルさん！ でも、これは正確に動作を保証するために必要な時間なんです！ 私の書いたテスト、中身を確認してください！」

ルルが奪い取るようにマウスを操作し、ヒマリのコードを精査する。そこには「正確さ」を追求するあまり、現場を疲弊させる罠が張り巡らされていた。

1. テストを実行するたびに、DBに本物のテーブルを作成し、インデックスを張っている。

2. 数万件に及ぶマスターデータを、毎回律儀にインサートしている。

3. 外部APIとの通信をシミュレートするために、本物のネットワークプロトコルを立ち上げている。

ルル： 「ヒマリさん、これはテストではなく『苦行』です。一か所の小さなタイポを修正するのに10分、その確認テストに40分。これでは一日に、一体何回のサイクルを回せると思っているのですかッ！😤」

ヒマリ： 「……一日、多くて10回……いえ、もっと少ないかもしれません。」

ルル： 「そうです。人間は、結果が返ってくるまで10秒以上かかると、その間に別のことを考え始めてしまいます。ましてや40分。その間、あなたの思考は完全に分断され、集中力という名の貴重な燃料は蒸発して消えてしまいますッ！！😤」

ルルはモニターを指差したまま、断言した。

ルル： 「テストが遅いということは、開発者がテストを実行しなくなるということです。実行されないテストに、価値などありません。それは『品質の盾』を、自ら温泉に投げ捨てるのと同じ、プロとしてあるまじき行為ですッ！！😤」

♨️ 単体テストが、開発の「心拍」を速める

項垂れるヒマリに、マリが優しく語りかける。彼女の持つカップからは、いつもの穏やかな香りが漂っている。

マリ： 「ヒマリちゃん。結合テスト（Integration Test）の重要性は、誰も否定しないわ。本物のDBに繋ぎ、本物の環境に近い状態で動かすことは、最後の最後で必要なプロセス。……でもね、日々の開発のリズムを作るのは、それではいけないのよ。☕」

ヒマリ： 「リズム……。」

マリ： 「そう。ミリ秒単位で終わる『単体テスト（Unit Test）』を主軸に置くべきなの。☕」

マリはホワイトボードに、ピラミッドの図を描いた。

マリ： 「DBやネットワークといった、重くて不安定な外部要因を切り離して、あなたの書いたロジックの純粋な『正しさ』だけを高速に検証する。それが単体テスト。40分かかる大きな検証を1回するよりも、0.1秒で終わる小さな検証を1万回できる環境のほうが、ソフトウェアは遥かに健全に育つのよ。☕」

サキ： 「そうなんだよね。✨ テストが爆速になれば、失敗しても全然怖くないでしょ？ 『あ、間違えた』って思っても、すぐに直してまたボタンを押せる。その『やり直しの安さ』が、エンジニアの創造性を守るんだよ。✨」

ユイ： 「あぅ……っ。……テストが早くなれば、失敗を恐れずに……どんどんコードを直せるようになるんだねぇ……っ。それはまるで……開発者の鼓動が、コードに伝わっていくみたいだね……っ。」

ユイの詩的な言葉に、ヒマリはハッとした。 自分が今まで「正確さ」だと思っていたものは、実は開発のスピードを奪い、自分の挑戦する心を萎えさせていた重石だったのだ。

ヒマリ： 「40分を4秒に。……。いえ、もっと速く。テストを『重荷』にしないために、DBやインフラからロジックを切り離す設計を考えます！ 開発の鼓動を止めない盾、私が作ります！」

東根温泉の夜空には、満天の星が輝き始めている。 ヒマリは再び、今度はもっと軽やかな、そしてより熱のこもったリズムでキーボードを叩き始めた。

「盾」の重さは、もはや彼女を苦しめるものではなかった。 それは、彼女の疾走を支える、羽のように軽い、しかしダイヤモンドよりも強固な翼へと変わろうとしていた。

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

皆さんは、テストコードをどのような環境で実行していますか？

モダンな開発現場において、GitHub Actionsなどに代表されるCI/CDパイプライン上でテストを自動実行させることは、もはや「標準」と言っていいでしょう。ローカルで検証を終えたコードをPUSHし、クラウド上で自動的にテストが走る。このワークフローこそが、現代の開発を支える背骨です。

こうした現場では、1日に数百回、数千回という単位でテストが繰り返されます。その中で、一度の実行に莫大な時間を要するテストコードが混じっているとしたらどうなるか。それは開発スピードを物理的に削り取るだけでなく、やがては「重すぎて誰もメンテナンスしたがらない」という、テストコードの形骸化を招く原因になります。

では、テストの実行時間が膨れ上がる元凶は何でしょうか。

私が体験したある現場では、テストを実行するたびにDBへ大量のマスタデータを投入し、テスト用のユーザーを何人も生成する……といった重厚なセットアップが、すべてのテストケースで律儀に走っていました。その上で、DB接続を必須とする結合テストが山のように積み上がっていたのです。

もちろん、DBを使った結合テストが必要な場面はあります。しかし、すべての機能、すべてのルートに対して結合テストを書く必要はない、というのが私の持論です。

私がテスト戦略を設計する際は、以下のようなポリシーを徹底しています。

• ビジネスロジック層のUnitテストを徹底する まずはメモリ内で完結するUnitテストで、ロジックの整合性を担保します。DBを介さないため、実行速度は圧倒的です。

• 例外や異常系はUnitテストでカバーする DBエラーなどの擬似的な状況を結合テストで再現するのは時間がかかります。モックを活用したUnitテストなら、瞬時に、かつ確実に行えます。

• 結合テストは「最小限」から始める APIを実際に叩くような重いテストは、開発当初は正常系が1つ通るかというスモークテスト程度に留めます。

• バグが出た時こそ、結合テストの出番 リリース後にバグが発覚した際は、その条件を再現する結合テストを追加し、再発防止の「防壁」として機能させます。

さて、こうしたポリシーを最後まで守り抜けるかどうかは、結局のところ「設計」にかかっています。

システム全体を「3層構造（プレゼンテーション層・ビジネスロジック層・データアクセス層）」に分離することで、どこで、どのレベルのテストを書くべきかが初めて明示的になります。

もし、データアクセス層にビジネスロジックを紛れ込ませてしまったらどうなるか。ロジック一つを検証するために、わざわざDBを立ち上げ、データを投入し、コネクションを張るという「やらなくていいテスト」を増やすことになります。必然的に結合テストの比率が上がり、実行時間は雪だるま式に膨れ上がっていくでしょう。

「テストが遅い」という悲鳴は、設計が混濁しているという警告でもあります。 どこに何を書くかを分ける。そのシンプルな設計の規律こそが、爆速で走り続ける「盾」を作るための唯一の解なのです。

（つづく）

#エンジニア #プログラミング #テストコード #ユニットテスト #単体テスト #ソフトウェア開発 #開発効率 #生産性向上 #リファクタリング #クリーンコード #フィードバックサイクル #東根温泉秘密結社 #テストピラミッド #スピード重視 #技術的負債