4
コード契約を使用してアプリケーションを開発している場合は、このコンセプトがEiffelプログラミング言語で導入されたことがわかります。コード契約を結んでいる場合は、単体テストが必要ですか？
System.Diagnostics.Contractsを使用している私のC＃アプリケーションでこの概念を試した後、私は非常に混乱してきました。
私のための主な質問は次です：あなたは、コードの契約を持っている場合
は、本当に必要なユニットテストはありますか？ユニットテストフレームワークは、通常は提供しないことの主な相違点、の
一つ、（そのshimsとMS fakesライブラリを除く）プライベートメソッドをコールする可能性があります。これは、補助的な構成&の考え方のために、プライベートメソッドはパブリックメソッド呼び出しの対象となっているためです。
コード契約に関しては、Contract.RequiresとContract.Ensuresをプライベートメソッドとして宣言できます。
私はコード契約をしているときに、なぜ動作が非常によく似ているのか、単体テストが必要なのはなぜですか？
ありがとうございました
テストしたいすべてのアスペクトのコード契約を作成できますか？そして、契約システムは、それらの契約のすべてを（ビルド時に）チェックすることができますか？それは私にはそう思わない。 –
@ JonSkeetバグのない製品を（特定のバージョンで）使用したい場合は、コードカバレッジを非常に高くする必要があります。単位テスト（私が常に100％達成しようとしているところ）では、コード契約に関しても同じことをやろうとします。また、TDDの振る舞い（各サイクルR-> G-> R）は、個々の目標ごとにクリーンなコードを開発することを前提としています。前の手順を完了していないときに別のものに切り替えることはできません。 –
コードカバレッジは、正直なところ、コード品質にとって特に良いプロキシメトリックではありません。コーナーケースを実際に考えずに100％コードカバレッジを持つことは可能です。 –