単体テスト
単体テストはいわばシステムの生きた技術文書を提供する。 開発者がユニットにどのような機能があるかどのように使用すればいいかを知るためには単体テストを調べてユニットのAPIの基本を理解すればよい。
単体テストケースはそのユニットの正常動作に必要不可欠な特性を持っている。これらの特性は、ユニットの適切/不適切な使用を示すだけでなく、ユニットにトラップされるネガティブな動作を示す。単体テストはそれ自身とその内部において重要な性質をドキュメント化している。しかし、多くのソフト開発環境は開発中製品をドキュメント化するためにコードだけには頼らない。
それに比べて、普通の手作業のドキュメントはプログラムの実装から押し流される傾向にあり、陳腐になりがちである(例えば、設計変更、機能追加、ドキュメント最新化の習慣の緩和など)。
単体テストを書くことに関連するもう一つの課題は、現実的かつ有用なテストを設定することの難しさである。テスト対象アプリケーションの一部が、完全なシステムの一部のように振る舞うように関連する初期条件を作成する必要がある。これらの初期条件が正しく設定されていない場合、テストにおいて現実的なコンテキストでコードが実行されず、単体テスト結果の価値と正確性が減少する。
単体テストで意図通りの効果を得るためには、厳格な規律がソフトウェア開発プロセス全体で必要となる。実行済のテストだけでなく、ソースコードまたはソフトウェア内の他のユニットに加えられたすべての変更についての正確な記録を保持することが不可欠である。バージョン管理システムの使用が不可欠である。より新しいユニットのバージョンが以前に合格したという特定のテストで失敗した場合、バージョン管理ソフトウェアでは、(もしあれば)それ以降にユニットに適用されたソースコードの変更のリストを保持している可能性がある。
また、失敗したテストケースが毎日検証され、すぐに対処されることを確実にするための、持続可能なプロセスを実装することが不可欠である。このような処理が実装されず、チームのワークフローに深く根付いていない場合、アプリケーションの進化が単体テストスイートとの同期を失い、偽陽性が増加し、テストスイートの有効性が低下することになる。
組み込みシステムソフトウェアの単体テストには、他にない課題がある。ソフトウェアは、最終的に実行されるものとは異なるプラットフォーム上で開発されているので、デスクトッププログラムでテスト可能であっても、実際のデプロイ環境で容易にテストプログラムを実行することはできない。