少ない値の範囲でのこのメソッドの動作を規定する。}}この場合、単体テストは最初に書かれているため、求められる解決策の形と挙動を示す設計ドキュメントの役割を果たす。それは細部の実装ではなく、実装はプログラマーに任せられている。「動きそうな最もシンプルな事を行なう」慣例に従えば、テストをパスできる最も簡単な解決法は以下のようなものだろう。}}図を使う他の設計手法とは異なり、単体テストを設計の手段として使用することには重要な利点が1つある。設計文書(単体テストそのもの)を実装が設計に準拠していることを確認するために使用できるのだ。単体テスト設計方法においては、開発者が設計通りに解決策を実装していない場合、テストはパスすることは決してない。図はこんにち、フリーのツールにより大部分の近代的な言語から自動的に抽出できる(通常IDEの拡張機能として)。xUnitフレームワークに依存するフリーのツールは、人の目で見られるためのグラフィカルレンダリング機能を他のシステムにまかせている。他のクラスを参照しているため、あるクラスのテストはしばしば別のクラスのテストに影響してしまう。データベースに依存しているクラスである。クラスをテストするために、テスタは、しばしばデータベースと対話するコードを書く。単体テストは自分のクラスの境界を超えるべきではないし、特にそのようなプロセス/ネットワーク境界を超えることは許されない。その理由は単体テストスイートで受け入れがたい性能問題が起こりうるからである。そのように単体テストの境界を超えることは統合テストになり、テストが失敗したときに、そのコンポーネントが失敗に原因かどうかがわからない。フェイク、モック、統合テストを参照。その代わりに、ソフトウェア開発者は、データベースクエリの周りに抽象的なインタフェースを作成し、専用のインターフェイスを持つモックオブジェクトを実装する必要がある。この必要な付属物をコード(ネットで有効な結合)から抽象化し、独立したユニットは以前よりも徹底的にテストすることができる。この結果、高品質でかつ保守性があるユニットができあがる。Testing)はパラメータが必要なテストである。通常の単体テストは、閉じたメソッドであるが、PUTはいかなるパラメータも取りうる。4と様々な.NETテストフレームワークによってサポートされてきた。単体テストに適したパラメータは手作業で作成、あるいは、テストフレームワークにより自動生成される場合もある。QuickCheckのようなテスト入力を生成する商用テストツールも多い。単体テストの制限[編集]もっとも簡単なプログラムでさえも、すべての実行パスを評価するわけではないので、テストでプログラムのエラーが全てわかるわけではない。同じことは、単体テストにも当てはまる。単体テストは、その定義からユニットのみの機能自体をテストする。したがって、統合エラーや、より広範なシステム·レベルのエラー(例えば性能など、複数のユニットにまたがって実行される機能や非機能テスト領域)を捉えることはできない。単体テストは、特定のエラーの存在や不在を示すだけで、エラーが無いことの証明にはならないから、他のソフトウェアテスト活動と合わせて実施しなければならない。各実行パスの正しい挙動を保証するため、エラーの不在を確認するため、他のテクニックが必要となる、すなわち、ソフトウェアコンポーネントが期待されない挙動を示さないことを証明する正式なメソッドのアプリケーションが必要となる。ソフトウェアテストは、組み合わせ問題である。2分する判定ステートメントは少なくとも2つのテストが必要である。結果が真となる場合と、偽となる場合である。結果として、多くの場合、作成コードの1行あたり、プログラマは3から5行のテストコードを書かなければならない。これは明らかに時間がかかり、その手間を投資する価値はないかもしれない。非決定的あるいは複数スレッドが関係する場合、テストは容易ではない。単体テスト用のコードには、少なくともテスト対象コードと同じくらいのバグが存在する可能性がある。フレッド·ブルックスが人月の神話で述べたように、船に乗るときは、クロノメーターを2つ持って行ってはならない。常に1個か3個を持っていけ。クロノメーターが矛盾する場合、どちらが正しいのかわからないということである。単体テストを書くことに関連するもう一つの課題は、現実的かつ有用なテストを設定することの難しさである。テスト対象アプリケーションの一部が、完全なシステムの一部のように振る舞うように関連する初期条件を作成する必要がある。これらの初期条件が正しく設定されていない場合、テストにおいて現実的なコンテキストでコードが実行されず、単体テスト結果の価値と正確性が減少する。[6]単体テストで意図通りの効果を得るためには、厳格な規律がソフトウェア開発プロセス全体で必要となる。実行済のテストだけでなく、ソースコードまたはソフトウェア内の他のユニットに加えられたすべての変更についての正確な記録を保持することが不可欠である。バージョン管理システムの使用が不可欠である。新しいユニットのバージョンが以前に合格したという特定のテストで失敗した場合、バージョン管理ソフトウェアでは、(もしあれば)それ以降にユニットに適用されたソース·コードの変更のリストを保持している可能性がある。失敗したテストケースが毎日検証され、すぐに対処されることを確実にするための、持続可能なプロセスを実装することが不可欠である。このような処理が実装されず、チームのワークフローに深く根付いていない場合、アプリケーションの進化が単体テストスイートとの同期を失い、偽陽性が増加し、テストスイートの有効性が低下することになる。組み込みシステムソフトウェアの単体テストには、他にない課題がある。ソフトウェアは、最終的に実行されるものとは異なるプラットフォーム上で開発されているので、デスクトッププログラムでテスト可能であっても、実際のデプロイ環境で容易にテスト·プログラムを実行することはできない。[8]アプリケーション[編集]エクストリーム・プログラミング[編集]単体テストは、エクストリーム・プログラミングの基礎となるもので、それは自動化ユニット·テスト·フレームワークに依存している。この自動化ユニット·テスト·フレームワークは、xUnitのようなサードパーティ製、あるいは、開発グループ内で自作することができる。エクストリームプログラミングはテスト駆動開発での単体テストの作成​​を利用している。開発者は、ソフトウェア要件、または欠陥を暴露する単体テストを書く。要件がまだ実装されていないか、意図的に既存のコードの欠陥を暴露するため、このテストは失敗する。開発者は、そのテストと他のテストにパスするような最も簡単なコードを書く。システム内のほとんどのコードは、単体テストが実施されるが、コード中のすべてのパスである必要はない。「失敗する可能性があるすべてのテストを実行する」戦略を義務付けている。これにより、開発者が従来の方法よりも少ないテストプログラムを開発することにつながるが、古典的な方法においては、すべての実行パスが完全にテストされるほど十分念入りに実施されないため、これは大きな問題でなく、事実の言い換えである。エクストリームプログラミングというのは、テストが(しばしば高価すぎて時間がかかり経済的に実施可能でないため)、いかにして効果的に限られた資源を集中するかについて基本的な考え方を示している。重要なのは、テストコードは、重複を全て取り払い実装コードと同じ品質に維持されている点で、第一級のプロジェクト成果物であるという考えである。開発者は、テスト対象コードと対でコードリポジトリに単体テストコードを公開する。コード統合の容易化、正確なドキュメンテーション、モジュール化の高い設計である。これらの単体テストはまた、回帰テストとして頻繁に実行される。創発的設計の概念の重要な要素である。創発的設計はリファクタリングに大きく依存しているので、単体テストもまた不可欠な要素である。[9]テクニック[編集]単体テストは、通常自動化されているが、手動で実行されることもある。IEEEは、どちらかが片方より優れているとはしていない。手動による単体テストではステップ·バイ·ステップの手順書を利用することがある。いえ、単体テストをする目的は、ユニットを分離し、その正しさを検証することである。自動化は、これを達成するための効率が高く、本項に記載されている多くの利点を備える。テストで達成されるべき目標に達しない可能性がある。自動化アプローチを使用しながらも、独立効果を完全に実現するために、テスト対象ユニットやコード本体は、その自然環境の外のフレームワーク内で実行される。換言すれば、元々作成された製品または呼び出し元のコンテキストの外で実行される。そのような独立した形でのテストでは、テスト対象コードと他のユニットや製品内のデータ·スペースの間の不要な依存関係が明らかになる。依存関係は、その後、除去することができる。自動化フレームワークを使用しながら、開発者はユニットの正しさを検証するために、基準をコード内に反映させる。テストケースの実行時には、フレームワークのログ中に、基準に満たないテストが記録される。多くのフレームワークは自動的に失敗したテストケースにフラグを立て、まとめて報告する。障害の重症度に応じて、フレームワークは、後続のテストを停止する場合がある。凝集したコード本体を作成する動機づけとなる。これを常に行えば、ソフトウェア開発における健全な習慣がつくられる。デザインパターン、単体テスト、リファクタリングを組み合わせれば、最善の解決策が出るようになる。ユニット・テスト・フレームワーク[編集]この節の加筆が望まれています。(2010年4月)ユニット・テスト・フレームワークは、ほとんどの場合、コンパイラスイートの一部として配布されていないサードパーティ製品である。それはさまざまな言語のために開発され、単体テストのプロセスを簡素化するのに役立つ。VectorCAST/C++のようなプロプリエタリ/商用ソリューションがある。制御フロー機構を利用して失敗を通知するものである。フレームワークなしの単体テストは単体テストの採用に参入障壁がある場合有効である。少ない単体テストは全く無いよりもはるかにましであるが、一旦フレームワークが導入されれば、単体テストの追加は比較的楽になる。一部のフレームワークでは、多くの先進的な単体テスト機能が欠落しており、手でコーディングする必要がある。言語レベルの単体テストのサポート[編集]直接単体テストをサポートしているプログラミング言語もある。その文法は(サードパーティ製または標準の)ライブラリをインポートせずに単体テストを直接宣言することができる。単体テストのブール式条件が非単体テストコードで使用されるブール式と同じ構文で表現することができる。(ifとwhileの文のように)直接単体テストをサポートしている言語は以下の通り。2012年7月23日閲覧。2008年4月1日閲覧。2014年2月19日閲覧。2007年11月29日閲覧。2012年7月23日閲覧。2008年2月8日閲覧。2012年5月8日閲覧。2012年5月8日閲覧。2009年3月24日閲覧。2012年11月15日閲覧。(日時は個人設定で未設定ならばUTC)。表示-継承ライセンスの下で利用可能です。追加の条件が適用される場合があります。詳細は利用規約を参照してください。Cookieに関する声明モバイルビュ。