単体テストとは何か、なぜ必要なのか【前編】：はじめての単体テスト（3/5 ページ）

[ベクター・ジャパン，MONOist]

2.2　なぜ単体テストを行うべきなのか

　単体テストは、一般に、全テスト工程の中でテスト対象とするソースコード量が最も少ないテストとなります。そのため、不具合を発見した場合にソースコードの不具合箇所を特定しやすく、修正に掛かる時間が短くて済む点が利点として挙げられます。

　当然のことながら、単体テストで不具合を検出することができれば、後工程のテストフェーズでの不具合発生を防ぐことができます。不具合発見が後の工程になればなるほど、不具合が開発中のソフトウェアに与える影響範囲が大きくなり、手戻りが増えることになります。

　単体テストで不具合を発見した場合と、結合テストやシステムテストの段階で不具合を発見した場合では、不具合の修正に掛かるコストは大きく違ってきます。図2はIBMによる調査、図3はGoogleによる調査、図4は複数プロジェクトの分析の要約（約250プロジェクト）です。各テストフェーズで、大きくコストが違うことが分かります。

図2：各ソフトウェア開発ステージにおける、バグ修正にかかるコストの対比（クリックして拡大） 出典：ベクター・ジャパン

図3：各テストフェーズにおける、バグ修正にかかるコストの対比（クリックして拡大） 出典：ベクター・ジャパン

図4：要求仕様作成から生産までの各ステージにおける、バグ修正にかかるコストの対比（クリックして拡大） 出典：ベクター・ジャパン

　自動車業界では、不具合の検出コストよりも、リコールに伴う直接コストや製品ブランドへのダメージの方が影響として大きいため、徹底的なテストを行うことが必要不可欠となっています。そのことからも、単体テストで不具合を検出することが重要です。

2.3　レガシーコードへの対応

　単体テストを導入する際は、テストインフラが不十分であった時代に作られたレガシーコードに対し、どうテストを行っていくかを考える必要があります。社内のコード規約などが整備されていない時代に作られたレガシーコードを、リファクタリングせずに使い続けているケースも見受けられます。「うちのレガシーコードは改善しようがない」という声をお聞きすることがありますが、こうした姿勢では品質向上をかなえることは難しくなります。

　品質志向に移行するためには、テストは時間と手間がかかるものと認識し、取り組んでいかなければならないのですが、開発者のリソースは限られており、開発と並行してレガシーコードへのテスト環境構築を行うことは現実的ではありません。テストインフラを整えるためには、会社の方針としてリソースを割り当てる必要があります。例えば、ベテランのチームメンバーでグループを組み、単体テストの導入を先導することや、受託会社などを利用して単体テストを依頼するなど、テストインフラを整えるための費用を捻出する必要があります。

　レガシーコードは多くの場合、技術的負債を抱えていて、解決するためにはリファクタリングを行うか、レガシーコードのアプリケーションの正確性を確認するための回帰テスト環境を構築するしかありません。もちろん、どちらも非常に工数と費用が掛かる作業です。リファクタリングを行うことは影響範囲の確認を随時行う必要があるということなので、リファクタリングを行う際も回帰テストの環境を構築することが必要となります。ガートナーの調査には、「反復可能なテストケースがないと、客観的かつ測定可能な方法で機能等価性を実証しにくい」と記されています^（※3）。

（※3）Gartner Group；「Monitor Key Milestones When Migrating Legacy Applications」；2015年5月18日（参照：ベクター・ジャパン資料「ベースラインテスト：レガシーコードベースの技術的負債を減らす秘訣」；ホワイトペーパー | V2.0 2018-01）

　重要なことは、開発・テストのワークフローとメトリクスを設定し、ソフトウェア品質を高めるベストプラクティスを考えていくことです。その1つとして、回帰テスト環境の構築があります。日本の自動車業界のほとんどのお客さまがカバレッジを取得するテストケースを作成しており、カバレッジ取得100％を達成していますが、回帰テスト環境の構築を行っている会社は非常に少ないのが現状です。

　一方、海外の自動車開発業界では、回帰テスト環境を実現している会社が多くあります。この流れは、米国のソフトウェア企業が以前からテスト自動化環境を構築していたことも要因として考えられます。