AI開発時代だからこそ、テストの役割を見つめ直す

どのカラムにも、最も得意な不具合の種類があります。重なる所もありますが、検出できる度合いと、そのためにかかるコストが違います。 表を見ると、どのカラムにも ◎ が付く row があります。重なる所もありますが、同じ不具合を検出するにも、得意なテストなら安く確実に検出でき、不得意なテストでは偶然に頼るか、大きなコストがかかります。E2E テストでも計算の誤りに気づくことはありますが、境界値の組み合わせを何十通りも E2E テストで検証するのは現実的ではありません。逆に、ユニットテストやコンポーネントテストをいくら厚くしても、ページ遷移の後で前の画面の入力が引き継がれない、といった画面をまたぐ誤りには気づけません。どの種類も、ほかの種類では割に合わない所を受け持っています。 速さの違いも、役割の一部 AI に実装させ、テストが pass するまで修正させ、人は最初の指示と最後の確認を受け持つ。

[t-wada]

よくまとまっている

[nguyen-oi]

AIにテスト書かせるなら、人間は型の設計に注力して『読まなくていい状態』を作るっていうのは合理的。境界値自動化と相性良さそう