ソフトウェア開発の専門家は、ソフトウェア製品のテスト可能な最小のコンポーネントを指すのに「ユニット」という用語を使用し、ユニットが期待どおりに動作するかどうかを検証するプロセスを指すのに「ユニット テスト」というフレーズを使用します。過去 20 年間で、これらの専門家は自動化されたユニット テストにますます興味を持つようになり、「ユニット テスト フレームワーク」というフレーズは、自動化されたユニット テストを容易にするために使用されるメカニズムを指すようになりました。
JSL 開発者を含むソフトウェア開発者は、開発したソフトウェアが期待どおりに動作することを保証することに強い関心を持っています。この明らかな動機の他に、さらに 2 つの理由があります。
1. ソフトウェアの進化: ソフトウェアは時間の経過とともに進化します。通常、これは機能の追加や変更によるものですが、リファクタリングによってソフトウェアが進化することもあります。製品の検証に定期的に使用される、適切に維持されたユニット テスト ケース スイートにより、ソフトウェア製品が進化しても期待どおりの動作を維持することが保証されます。製品の進化に伴って後退する (壊れたり動作しなくなったりする) ユニットはすぐに特定されます。
2. 実行可能なドキュメント: ユニット テスト ケースは、ソフトウェア製品の予想される動作を文書化します。自動化されたユニット テストの利点の 1 つは、テスト ケースが実行可能なドキュメントとして機能することです。その結果、テスト ケースが製品の進化に合わせて定期的に使用され、検証される限り、静的に記述されたドキュメントとは異なり、これらのテスト ケースはソフトウェア製品の予想される動作を正確に反映する可能性が高くなります。
近年、ユニット テスト全般、特に自動ユニット テストの主な提唱者は、eXtreme Programming (XP) コミュニティです。このコミュニティの熱意もあって、現在では主要なプログラミング言語すべてでユニット テスト フレームワークが利用できるようになっています。
JMP がソフトウェア開発でユニット テストを使用する方法について詳しくは、JMP 開発者の Joseph Morgan と Xan Gregg による記事全文の添付 PDF をダウンロードしてください。
