テストコードをどこまで書くかを考える
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。
単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。
興味があれば、参考として読んでもらえると嬉しいです。
保守や運用の観点で見ると、プロダクションコードを修正した際に、既存のテストが壊れ、そのテストを修理しながら既存機能を担保していく、という点で、単体テストは有効に機能します。
一方で、テストカバレッジ100%のように、すべての分岐や条件を網羅するテストを書くことについては、費用対効果の面で疑問を感じることもあります。
どこかで「おおよそ75%程度を目安にすればよい」という話を聞いた記憶もあり、現実的な落とし所を探る必要があるように思います。
AIの力によって、さまざまなパターンのテストを比較的簡単に書けるようになった今だからこそ、どこまでテストを書くべきか、という点で迷いが生まれています。
テストコードを書いていなかった頃の開発体験
今から10年ほど前、SIerとして業務システムの新規開発に携わっていた頃、テストコードを書かずに開発を進めた経験があります。
当時はPHPを用いてWebサービスを構築しており、開発プロセスとしてはV字モデルを採用していました。
実装した機能は、画面を手動で操作して期待通りに動作することを確認し、その後Subversionに登録して次の機能実装へ進みます。
すべての機能実装が終わった段階で、Excelにまとめられたテスト仕様書をもとに、自分が実装していない画面に対して、ひたすら手動で確認作業を行っていました。
テスト中に不具合が見つかれば修正を行い、再び同じテストをやり直します。
このサイクルを繰り返し、ようやく納期に間に合わせて成果物を完成させ、本番環境へ反映し、最終的に発注元に操作してもらう、という流れでした。
手動テストは人が行う以上、どうしても見落としが発生します。
また、修正のたびに同じ操作を繰り返す必要があり、規模が大きくなるほど確認項目も増え、負担が大きくなっていきました。私が携わったプロジェクトでは、プロジェクトの関係のないメンバーを何十名もかき集めて、20人近くで みんなで手動テストしていたこともあります。
テストコードを書く理由の根っこ
このような経験から、手動テストを自動化したいという思いが、自分の中でテストコードを書く動機として根付いています。
テストと一口に言っても、いわゆるテストピラミッドの考え方のように、単体テスト、統合テスト、E2Eテストなど、役割は分かれます。
それでも、根底にある目的は昔から変わっていないと感じています。
- 手動テストにかかる時間を減らすこと
- 人による確認ミスを減らすこと
どこまでテストを書くかという判断
テストコードですべてのパターンを網羅することよりも、もし手動で確認するとしたら、どのような操作を行うかを意識しながらテストを書く方が、自分の好みに合っています。
数値のバリデーションのように、境界で挙動が変わるものについては、境界値を意識したテストを書きたくなりますし、プロパティベーステストのような手法を取り入れるのも自然だと思います。
また、複数の状態の組み合わせによって出力が変わるロジックについては、パラメタライズドテストが有効だと感じています。
個人的には、循環的複雑度が高そうなロジックについては、意図的にテストケースを厚めに書きます。
一方で、単純な処理については、代表的な1パターンを確認できれば十分と考え、その時点でテストを終えることも少なくありません。
サンプルコードを示さず、考え方だけを書き連ねましたが、今の自分のテストに対するスタンスは、このようなものです。最後までお読みいただきありがとうございました。
Discussion
とても共感しながら読みました。
特に「考えてテストを書く」という姿勢には強くうなずきました。惰性でケースを増やすのではなく、境界や意図を理解して質を上げていくという考え方は、本当に大事だと思います。
一方で、タイトルが少し強めで、記事の本質である “量より質” のメッセージが少し伝わりにくくなっているようにも感じました。内容を読むと「全通り書くな」ではなく「無理に網羅率を追うより、質を上げよう」という話だと分かるので、そこが前面に出るとさらに読者に届きやすい気がします。
他の記事も拝見して、テストにとても明るい方だということが伝わってきました。
もしご存じでしたら、HASTY法や直交表のように、効率よく網羅性を高めるテスト設計手法についての記事も読んでみたいと思いました。実務者にとって価値の高いテーマになると感じています。
ご丁寧なご指摘、ありがとうございます。
ご指摘のとおり、あらためて読み返してみると、タイトルはやや強い表現だったと思います。タイトル釣りしてしまったかもしません...。
結果として、記事の主旨である「量より質」という点が、十分に前面に出ていなかったかもしれません。
タイトルについては、いただいたご意見を踏まえて見直したいと思います。
執筆時の背景として、私は日頃から Web フロントエンドにおいて、さまざまな粒度のテストコードを書いています。
テスト内容の一部が重複することは許容している一方で、「手動テストするのかな？」と思うような場面に遭遇することがある（？）ので、どう考えようかと思い、勢いに任せて書いたのがが本記事でした。
最後まで読んでいただき、また建設的なコメントをお寄せいただき、本当にありがとうございました。
早速タイトルを変更されたんですね。
読者と一緒に考えていくような、とても良いタイトルだと感じました。
自分で書いたコードのテストだと、コードが見えているだけに「十分やった気」になってしまうことがあります。勢いで数をこなして満足してしまう自分もいて、そういう時こそモレが出やすいと感じています。だからこそ、網羅性はやはり大事ですよね。
とはいえ、冗長になりすぎるとしんどいので、効率化も同時に考えていかないといけないと心がけています。