単体テストの制限

ウィキペディア小見出し辞書

単体テストの制限

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2021/04/24 17:06 UTC 版)

「単体テスト」の記事における「単体テストの制限」の解説

もっとも簡単なプログラムでさえも、すべての実行パスを評価するわけではないので、テストでプログラムのエラーが全てわかるわけではない。同じことは、単体テストにも当てはまる。さらに、単体テストは、その定義からユニットのみの機能自体をテストする。したがって、統合エラーや、より広範なシステムレベルのエラー（例えば性能など、複数のユニットにまたがって実行される機能や非機能テスト領域）を捉えることはできない。単体テストは、特定のエラーの存在や不在を示すだけで、エラーが無いことの証明にはならないから、他のソフトウェアテスト活動と合わせて実施しなければならない。 各実行パスの正しい挙動を保証するため、エラーの不在を確認するため、他のテクニックが必要となる、すなわち、ソフトウェアコンポーネントが期待されない挙動を示さないことを証明する正式なメソッドのアプリケーションが必要となる。 ソフトウェアテストは、組み合わせ問題である。たとえば、2分する判定ステートメントは少なくとも2つのテストが必要である。すなわち、結果が真となる場合と、偽となる場合である。結果として、多くの場合、作成コードの1行あたり、プログラマは3から5行のテストコードを書かなければならない。これは明らかに時間がかかり、その手間を投資する価値はないかもしれない。例えば、非決定的あるいは複数スレッドが関係する場合、テストは容易ではない。また、単体テスト用のコードには、少なくともテスト対象コードと同じくらいのバグが存在する可能性がある。フレッド・ブルックスは著書『人月の神話』で「船に乗るときは、クロノメーターを2つ持って行ってはならない。常に1個か3個を持っていけ。」と引用している。その意味は、2個のクロノメーターが矛盾する場合、どちらが正しいのか分からないから、ということである。 単体テストを書くことに関連するもう一つの課題は、現実的かつ有用なテストを設定することの難しさである。テスト対象アプリケーションの一部が、完全なシステムの一部のように振る舞うように関連する初期条件を作成する必要がある。これらの初期条件が正しく設定されていない場合、テストにおいて現実的なコンテキストでコードが実行されず、単体テスト結果の価値と正確性が減少する。 単体テストで意図通りの効果を得るためには、厳格な規律がソフトウェア開発プロセス全体で必要となる。実行済のテストだけでなく、ソースコードまたはソフトウェア内の他のユニットに加えられたすべての変更についての正確な記録を保持することが不可欠である。バージョン管理システムの使用が不可欠である。より新しいユニットのバージョンが以前に合格したという特定のテストで失敗した場合、バージョン管理ソフトウェアでは、（もしあれば）それ以降にユニットに適用されたソースコードの変更のリストを保持している可能性がある。 また、失敗したテストケースが毎日検証され、すぐに対処されることを確実にするための、持続可能なプロセスを実装することが不可欠である。このような処理が実装されず、チームのワークフローに深く根付いていない場合、アプリケーションの進化が単体テストスイートとの同期を失い、偽陽性が増加し、テストスイートの有効性が低下することになる。 組み込みシステムソフトウェアの単体テストには、他にない課題がある。ソフトウェアは、最終的に実行されるものとは異なるプラットフォーム上で開発されているので、デスクトッププログラムでテスト可能であっても、実際のデプロイ環境で容易にテストプログラムを実行することはできない。