自動テストはどこまでやるべきか、線を引くのがアーキテクトの仕事になる

はい、どうもこんにちは佐藤です！

X を見ていたら、自動テストをどこまでやるのかが話題になっていました。

この手の話、毎回「書くか書かないか」で殴り合いになりますよね。そして毎回、決着がつかないまま流れていきます。

実は私、書かない側の話はもう書いてしまっているんです。

AI で伸びるのは、もともと強いチームだけだで、自分がテストコードを書かないと決めた案件の話と、AI 時代にはその判断が通用しなくなるという話をしました。あの結論は今も変わっていません。

なので今日は、その先をやります。

書く。書くとして、どこまで書くのか。

ここから先を決めるのが、これからのアーキテクトの仕事になると思っているのです。書いていきますね！

論点は 2 つある。「管理するのか」と「どこまでやるのか」

自動テストの話がこじれるのは、別々の論点を同時に殴り合っているからです。

分けましょう。論点は 2 つあります。

テストコードを管理するのか
どこまでのテストをするのか

1 つ目は、人間がテストコードをレビューして面倒を見るのか、AI に任せて結果だけを見るのかという軸です。リポジトリに残すかどうかという話ではありません。誰が責任を持つか、という話ですね。

AI 時代の考え方は、大きく 2 系統に分かれていくのだろうと思っています。

テスト駆動開発のように、テストだけを担保して AI に実コードを書かせる
仕様はよく分からないけれど、AI にテストコードを書かせて、重要なドメインのテストコードだけをレビューする

前者は人間がテストを握ります。後者は AI に握らせて、要所だけ人間が見る。どちらが正しいというより、チームがどちらを維持できるかの問題でしょう。

そしてもうひとつ、大きな前提が変わりました。

テストコードがメンテできるのだ、だったら書かないわけにはいくまい。

だって、AI が正しく実装して、動くかどうかの判断をして、最低限動くことを担保してから人間にレビューをさせる。そういう仕組みを作ろうとすると、テストコードはどうしても必要になりますよね。

かつて「メンテできないから書かない」と判断していた前提が、崩れたわけです。

だとすると、残る論点は 2 つ目に寄っていきます。どこまでやるのか、です。

深さの 4 軸は、「新人が引き継いだときの負担」で見てほしい

深さは、大きく 4 つに分かれますよね。

モックテスト
DB テスト
API テスト
E2E テスト

それぞれが何をテストしたいのかは、このブログを読んでいる方ならご存知でしょうから割愛します。

代わりに、別の観点で考えてみてほしいのです。

もし新人がこのシステムを引き継いだとき、そのテストをメンテできますか？

なぜこの観点かというと、テストコードが死ぬのはいつも引き継ぎのタイミングだからです。書いた本人がいる間は、どんなテストも生きています。問題はそのあとですよね。

並べてみましょう。

軸	引き継いだ人に必要なもの
モックテスト	対象ドメインのアグリゲートと、対象となるユースケースの知識
DB テスト	それぞれの DB に合わせた技術力。加えて、なぜこのテストが必要になったのかの背景
API テスト	業務の一連の流れとユースケースの理解
E2E テスト	システムテストクラスの、全体の流れの理解

上から下に行くほど、必要なものが「技術」から「業務の理解」に変わっていくのが分かりますでしょうか。

モックテストは、極端な話その塊のことだけ分かっていればメンテできます。アグリゲートの中で閉じているからですね。

ところが E2E まで行くと、システム全体で業務がどう流れるかを頭に入れていないと、1 行も直せません。

ここが効いてきます。技術は勉強すれば追いつきますが、業務の理解は引き継がないと手に入らないのですよ。そして引き継ぎは、たいてい失敗します。

なお、モックテストと DB テストの使い分けそのものについては 4層かクリーンアーキテクチャかは、使うDBが決めるに書きました。モックがどれだけ実 DB とズレるかは DB 製品が決める、という話です。そちらとは重ならないよう、ここでは深さの線引きに絞ります。

私はこうやって、上から順に断念してきた

偉そうに書いていますが、私自身は**全部やれていません。**上から順に落としてきました。

正直に書きますね。

E2E テスト

失敗しか見ていません。

RPA が転けやすいのと同じ話です。些細な表示速度や、配置の違いで動かなくなってしまうのですよ。ボタンが 10 ピクセル動いただけで真っ赤になります。

そして直すのが誰かというと、人なんですよね。一連の動作をイメージしながらコードを書ける人は、そんなに多くありません。

DB テスト

これは環境の壁でした。

テストテーブルの作成が必須になります。ところが、Docker をまともに使える技術者が足りない。

導入したところで、環境が壊れたときに直せる人がいなければ、そのテストは次の四半期には止まっています。メンテが続かないと判断しました。

API テスト

連携が絡むと難しいです。相手のシステムが落ちていたら赤くなりますし、テストデータの整合も取らないといけません。

これまたデータの管理に労力がいるので、断念しています。前の案件では、雑に GET だけ扱っていました。参照系だけなら壊れにくいですからね。

線を引いていたのは、AI の能力ではなかった

ここで、書きながら気づいたことがあります。

上の 3 つ、どれも「技術的にできなかった」話ではありません。

E2E … 一連の動作をイメージできる人が少ない
DB … Docker をまともに使える技術者が足りない
API … データ管理の労力が持たない

全部、人間側の維持力の話なんですよ。

テストが書けなかったのではなく、書いたあとに生かしておけなかったのです。

つまり、これまで深さの線を引いていたのは、技術の難しさではありませんでした。チームがそれを維持できるかどうかでした。

だから私は、線をモックテストに置いてきたわけです。アグリゲートの知識だけでメンテできる範囲。そこなら、人が入れ替わっても死なないからですね。

今の AI は、自分のコードなら DB テストまで書ける

では、AI が入るとこの線はどう動くでしょうか。

いまの AI を人にたとえるなら、ミドルクラスのエンジニアくらいだと感じています。賢いし、まとまったものを書いてきます。

その前提で見ると、自分で書いたコードのテストコードを書けるのは、DB テストまでだと思っています。

モックテストは当然書けます。DB テストも、スキーマを渡せばテストテーブルの用意から書いてくれますよね。ここまでは、AI の中で話が閉じているからです。

でも API テストから先は変わります。

業務の一連の流れは、コードのどこにも書いていないからですよ。「この受注は与信を通ったあとでないと出荷に進まない」といった話は、実装を読んでも出てきません。人が知っているだけです。

E2E に至っては、システム全体で業務がどう流れるかが必要になります。ここは AI の外側にある情報ですよね。

AI が埋めるのは「手」で、埋まらないのは「理解」

ここまでで、線を動かす要因が 2 つに整理できました。

AI は、技術的な手数を埋めてくれます。

「Docker をまともに使える技術者が足りない」で断念した DB テスト。あれは今なら、compose ファイルも初期データの投入スクリプトも AI が書きます。技術力が足りないから諦める、という理由は弱くなりました。

私が線をモックに置いていた理由のうち、技術側の制約はかなり溶けたわけです。

でも、業務の理解は埋めてくれません。

API テストと E2E テストが要求しているのは、技術力ではなく仕様の理解でした。そして仕様の理解は、コードにも設計書にも残っていないことが多いですよね。この話は AI時代の炎上案件で本当に怖いのは「コードのバグ」じゃない。「仕様の理解負債」だに書いたとおりです。

AI が来ても、誰も業務を理解していないなら、E2E は書けません。

正確には、書けます。書けますが、**それが正しいかを判断できる人がいない。**何が正しいテストなのか分からないまま緑になっているテストは、ただの安心料ですよね。昔さんざん見てきた、あの真っ赤なエディタと同じ末路をたどります。

なので、私の中ではこう整理がつきました。

深さの線は、AI が下げてくれる分と、人間が理解している分の、低い方で決まる。

技術的な手数は AI が埋めます。だから DB テストまでは、以前より気軽に踏み込めるようになりました。その先へ行けるかどうかは、そのチームに業務を語れる人がいるかにかかっています。

まとめ

というわけで、**自動テストはどこまでやるべきか、線を引くのがアーキテクトの仕事になるよ！**って話でした。

論点を 2 つに分けるところが出発点でしたね。

テストコードを管理するのか … 人間が見るのか、AI に任せて結果だけ見るのか
どこまでのテストをするのか … モック / DB / API / E2E のどこで線を引くか

そして深さを選ぶときは、テストの中身ではなく 「新人が引き継いだときに、それをメンテできるか」 で見てください。技術で解ける部分は AI が埋めてくれますが、業務の理解が要る部分は残ります。

ちなみに私はというと、テストコードは AI に書かせて、最低限動作することを確認して人間の負荷を下げる運用です。深さはモックテストで線を引くことが多くなっています。

ただしこれは一例です。チームによって、業務を語れる人がいるかどうかは全然違いますからね。正解を配るつもりはありません。

まずは、いま持っているテストを 4 軸に並べてみてください。**自分たちがどこまでやっているのか、意外と言葉にできないものですよ。**棚卸ししてみると、線を引き直すべきところが見えてくるはずです！