安心を得るためにテストコードを書く
はじめに
先日、リファラジで「安心を得るためにテストコードを書いているが、AIが生成するテストが安心できない」という話を聞き共感しました。 自分もまさに「安心を得るため」にテストを書いています。バグを防ぐため、品質保証のためといった建前ももちろんありますが、本音を言えば「安心してコードを変更できるようにするため」です。
「安心のため」という動機
「テストは安心のため」という動機は極めて健全な動機だと思います。 なぜなら、ソフトウェア開発、特に自社サービスの開発は継続的に変更を加え続ける営みだからです。
- リファクタリングしたい
- 新機能を追加したい
- 依存ライブラリをアップデートしたい
これらすべてに「既存の機能を壊さないか」という不安がつきまといます。この不安を感じること自体が、エンジニアとして健全な姿勢だと思います。
不安の濃淡に応じたテスト戦略
自分は単体テストを書くとき、不安の大きさに応じてテストの手厚さを変えています。
手厚くテストを書く箇所
- ビジネスロジックが複雑な部分
- 過去にバグが出やすかった部分
- 複数の条件分岐がある部分
薄めに書く箇所
- ロジックがシンプルなクラス
- フレームワークが保証している部分
これは「完璧なカバレッジ」を目指すのではなく、「自分が安心して眠れるライン」を探る作業です。
AIとテストコード生成の課題
最近は自分もテストコードをAIに書いてもらうことが多いです。ただ、何も指定しないと下記のような問題が起きます。
- 過剰にテストケースを生成する
- 生成されたテストが本当に有用か判断するのに時間がかかる
対策：カバレッジ指定でコントロール
プロンプトでどのカバレッジレベルを満たすかを明示的に指定することで、ある程度コントロールできます。
このコードに対して、C1カバレッジ（分岐網羅）を満たす
最小限のテストコードを生成してください
- C0（命令網羅）：すべての命令を最低1回実行
- C1（分岐網羅）：すべての分岐を最低1回通過
- C2（条件網羅）：すべての条件の真偽を網羅
不安が大きい箇所ではC2、それ以外ではC1、といった使い分けができます。
ただし、最終判断は人間がする必要があります。AIが生成したテストコードを盲信するのではなく、「これで自分は安心できるか」という視点でレビューすることが重要です。
まとめ：不安は健全、それを安心に変えるのがテスト
「コードを変更することへの不安」を感じるのは、プロとして健全な姿勢です。 ユーザーに迷惑をかけたくない。壊したくない。そういう不安があるからこそ、品質の高いソフトウェアを作れます。
テストコードは、その不安を低減したり取り除くアプローチです。
完璧なカバレッジを目指す必要はありません。自分が「これで安心して変更できる」と思えるラインを見つけて、そこに向けてテストを書く。 それが、長く健全に開発を続けるための、現実的な戦略だと思います。
参考
- https://refactoradio.com/episode/100
- https://refactoradio.com/episode/101