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

　各ソフトウェアツールでは、要求される信頼水準（Tool Confidence Level；TCL）を分析することが求められています。もし、単体テストツールに対してツール認証が必要と判断された場合でも、機能安全認証を取得している単体テストツールを使用すれば、あらためてツール認証を取得する必要はありません。

　あくまで、機能安全はベストプラクティスであり、ツール認証を取得していないツールで単体テストを行っていたり、クロスコンパイルしていない環境でテストを行っていたりする場合もあります。しかし、ベストプラクティスとしては認証を取得している単体テストツールの使用が推奨されます。

2　なぜ単体テストが必要なのか？

2.1　なぜ単体テスト工程は飛ばされてしまうのか

　自動車のソフトウェア開発に携わっていて、ISO 26262に準拠した開発を行っている方々は単体テストを実施していると思いますが、ほかの組み込み業界では単体テストを行っていない会社が多いのが現状です。なぜ、単体テスト工程は飛ばされてしまうのでしょうか。

　その要因として考えられるのは、単体テストには非常に時間がかかるという点です。また、単体テストが実施されていない膨大なレガシーコードに対してテストをするためのコストを試算すると、余りにもコストが高く、結局は単体テストを行わないという判断になってしまうことも考えられます。

　単体テストに時間がかかっている場合は、古典的な単体テストを行っている可能性があります。例えば、テストドライバーやスタブのコードを書いていたり、無償のテストツールを使用していたりすることにより自動化が進んでいないことが背景にあるのかもしれません。

　こうした、工数が掛かるという問題に対しては、自動化をサポートする有償の単体テストツールの使用が有効な解決法だといえます。ツールを導入したうえで、まずは新しく追加する機能に対して単体テストを行っていくことが重要です。さらには、システムの中で複雑だと思われる部分に対して単体テストを行うことも効果的です。いずれにしても、まずは小さい範囲から単体テストツール導入の効果を測定していくことをお勧めします。

　多くの開発者が「単体テストを行いたい」という気持ちを持ってはいるものの、単体テストを行うためには開発のワークフロー自体を変えていく必要があり、そのことが単体テストツール導入の妨げになっているようです。また、開発しなければならないソフトウェアが増えていく一方で、社内のソフトウェア開発者数は増えないといった問題もあるでしょう。社内のリソース不足の問題が、新たなツール導入の妨げとなっているとも考えられます。

　開発のワークフローという点で見ると、日本では開発部門と評価部門が分かれている企業が多く、実装を全て終えた後に単体テストフェーズへ移行するという会社が多いのですが、効率的なテストを行うためには、実装してすぐにテストを行うことが理想的です。海外の自動車メーカーでは、実装後に細かい単位で単体テストを行うことが求められるケースも出てきています。

　自動車の開発現場では、ソフトウェアの評価を専門に行う部署を立ち上げている先進的な企業もあります。このようなソフトウェアのテストを行う仕組みを会社として作っていくことが必要になってきていることがうかがえます。