単体テストを全通り書くんじゃない！
AIの進化によって、プロダクションコードに対するテストコードは、以前と比べて格段に書きやすくなったと感じています。
単体テストに関する基本的なお作法については、以前に以下の記事で整理しました。
興味があれば、参考として読んでもらえると嬉しいです。
保守や運用の観点で見ると、プロダクションコードを修正した際に、既存のテストが壊れ、そのテストを修理しながら既存機能を担保していく、という点で、単体テストは有効に機能します。
一方で、テストカバレッジ100%のように、すべての分岐や条件を網羅するテストを書くことについては、費用対効果の面で疑問を感じることもあります。
どこかで「おおよそ75%程度を目安にすればよい」という話を聞いた記憶もあり、現実的な落とし所を探る必要があるように思います。
AIの力によって、さまざまなパターンのテストを比較的簡単に書けるようになった今だからこそ、どこまでテストを書くべきか、という点で迷いが生まれています。
単体テストを書いていなかった頃の開発体験
今から10年ほど前、SIerとして業務システムの新規開発に携わっていた頃、単体テストコードを書かずに開発を進めた経験があります。
当時はPHPを用いてWebサービスを構築しており、開発プロセスとしてはV字モデルを採用していました。
実装した機能は、画面を手動で操作して期待通りに動作することを確認し、その後Subversionに登録して次の機能実装へ進みます。
すべての機能実装が終わった段階で、Excelにまとめられたテスト仕様書をもとに、自分が実装していない画面に対して、ひたすら手動で確認作業を行っていました。
テスト中に不具合が見つかれば修正を行い、再び同じテストをやり直します。
このサイクルを繰り返し、ようやく納期に間に合わせて成果物を完成させ、本番環境へ反映し、最終的に発注元に操作してもらう、という流れでした。
手動テストは人が行う以上、どうしても見落としが発生します。
また、修正のたびに同じ操作を繰り返す必要があり、規模が大きくなるほど確認項目も増え、負担が大きくなっていきました。私が携わったプロジェクトでは、プロジェクトの関係のないメンバーを何十名もかき集めて、20人近くで みんなで手動テストしていたこともあります。
テストコードを書く理由の根っこ
このような経験から、手動テストを自動化したいという思いが、自分の中でテストコードを書く動機として根付いています。
テストと一口に言っても、いわゆるテストピラミッドの考え方のように、単体テスト、統合テスト、E2Eテストなど、役割は分かれます。
それでも、根底にある目的は昔から変わっていないと感じています。
- 手動テストにかかる時間を減らすこと
- 人による確認ミスを減らすこと
どこまでテストを書くかという判断
単体テストですべてのパターンを網羅することよりも、もし手動で確認するとしたら、どのような操作を行うかを意識しながらテストを書く方が、自分の好みに合っています。
数値のバリデーションのように、境界で挙動が変わるものについては、境界値を意識したテストを書きたくなりますし、プロパティベーステストのような手法を取り入れるのも自然だと思います。
また、複数の状態の組み合わせによって出力が変わるロジックについては、パラメタライズドテストが有効だと感じています。
個人的には、循環的複雑度が高そうなロジックについては、意図的にテストケースを厚めに書きます。
一方で、単純な処理については、代表的な1パターンを確認できれば十分と考え、その時点でテストを終えることも少なくありません。
サンプルコードを示さず、考え方だけを書き連ねましたが、今の自分のテストに対するスタンスは、このようなものです。最後までお読みいただきありがとうございました。
シェアする
フォローする
関連する記事
タグ「テスト」の記事
Web のフロントエンド実装において、次のようなミスによってデザイン崩れを起こしてしまったことはありませんか。 flex-shrink の指定を忘れて、要素が押しつぶされてしまった z-index の指定を間違えて、要素が意図せず前面（また
はじめに Playwright で E2E テストを書く際、playwright codegen や、近年では Playwright MCP を利用して、テストコードの雛形を作成することが多いと思います。 ただし、生成したテストコードが正し
2025-12-26
Storybook の Story オブジェクトを Vitest の Browser Mode だけで、Visual Regression Test（VRT）ができるようになりました。 本記事では、その導入手順をコンパクトに紹介します。 前