単体テストについてかなりの知識があります。コード契約について読み込もうとしています。それは本当に単体テストに役立ちますか? 特にユニットテストを行うのに役立つコードコントラクトについて話すとき、それは過大評価されていますか? 私は特に .net 4.0 のコントラクトについて言及しています。単体テストにはnunitを使用しています。
3 に答える
はい、いいえ。単体テストは基本的に、MyMethod()がXを受け取り、Yが結果になることを期待するという契約です。それが行われない場合、単体テストは失敗し、MyMethod()の開発者としてあなたが破ったことを警告されます。その中の何か。コードコントラクトは、単体テストを作成するのに役立ちます。これは、コントラクトの要件により、単体テストを作成するときに単体テストの要件を簡単に知ることができるためです。ただし、コードコントラクトの本当の理由はあなたのためではなく、あなたが作成したAPIを使用している他の開発者のためです。単体テストは適切な入力と出力を通知しますが、コードを公開する場合、単体テストは.dllではリリースされません。コード契約は他のものを与える開発者は、コンパイル時のコントラクトとチェックを通じて、同じ要件を知ることのメリットを享受できます。コントラクトは、メソッドのドキュメントを読まずに物事を渡し始めるという恐ろしい傾向がある開発者(私)から保護するため、コントラクトを通じて積極的に警告されるようになります。
コードコントラクトは、単体テスト(インターフェイスのコントラクト)を使用できないものに使用できます。それらは継承チェーンに適用されます(手動の単体テストで簡単に間違いを犯す可能性があります)。それらは自動的にドキュメントを提供します(ユニットテストではできないこと)。それらは本番環境でランタイムチェックを提供できます(単体テストでは実行できないもの)。
一方、コントラクトは実行された場合にのみ失敗するため、単体テストがないと、コードの品質は保証されません(つまり、すべてのコードがさまざまなコントラクトを満たします)。2つの概念は補完的です。
いいえ、コードコントラクトが単体テストの作成に役立つとは思いません。単体テストは、特定のアクションの動作と制約を定義します。単体テストで記述された仕様の1つは、メソッドへの引数をnullにすることはできないというものかもしれません。
その場合でも、単体テストを作成する必要があります。コードコントラクトは仕様を実装する方法ですが、唯一の方法ではありません。
言い換えれば、コードコントラクトを使用することは、単体テストを作成する必要がないことを意味すると想定しないでください。誰かがコードコントラクトを変更したり削除したりしても、意図した仕様が失敗したことを示すテストはありません。