Debug.Assertとコード契約の使用

Question

コード契約をデバッグするときはどうしたらよいですか？私は方法の前提条件を確認したいと思うし、もう一方を選択するのは混乱している。私は、障害シナリオをテストし、例外を予想したいところで単体テストを行います。

同じメソッドでDebug.AssertとCodeコントラクトを使用することをお勧めします。もしそうなら、コードを書かなければならない順序は何でしょうか？

Debug.Assert(parameter!= null); 
Contract.Requires<ArgumentNullException>(parameter != null, "parameter"); 

または

Contract.Requires<ArgumentNullException>(parameter != null, "parameter"); 
Debug.Assert(parameter!= null); 

その背後にある任意の論理的根拠はありますか？

Answer 1

これは別のものです。デバッグアサートは、コードがデバッグとしてコンパイルされている場合にのみ実行されるため、デバッグ時にのみチェック/アサートされます。考えているのは、開発中のコードに対してこれを「健全性チェック」に使用することです。コード契約は、デバッグまたはリリースで使用できます。彼らは、メソッドの前後の条件がメソッドの期待に従うことを保証します（契約を満たす）。同様の機能を提供するテストフレームワークもあり、テストコンプライアンスをチェックするために設計されています。

コードを開発するとき（および後でメンテナンスの開発時に）特定のことを期待したいときは、Debug.Assertを使用します。

デバッグとリリースの両方で条件が満たされるようにする場合は、コード規約を使用してください。契約では、プログラムが「正しい」ことを確認するのに役立つ静的分析の特定の形式も許可されます。

単体テストの作成時に、テストフレームワークアサーションを使用します。

Answer 2

私はDebug.Assertと新しく書かれたコードの前提条件を強制するためのコード契約（IMOコード契約はDebug.Assert）の両方を個人的には使用しません。より包括的なチェックを提供します。コードが実行される前にの実行可能な静的検査がに実行されます。 Debug.AssertとContractsの両方で重複した前提条件チェックを維持するのは面倒です。

理由：

• あなたが再コードにあなたがDebug.Assertまたはthrowコードでコード化されている可能性のある従来の前提条件を必要としない - あなたは、既存の前提条件のチェックコードを保つことができるとterminate it with Contract.EndContractBlock()
• あなたはがNoneに設定された契約実行時間チェックを使用してビルドする場合、/d:DEBUGを除いてビルドされている場合と同じチェックされていない「リリースモード」の動作を得ることができます。 Ref 6.2.1 in the Docs
• 契約では、「無効な状態が検出されました」という意味で、開発者はコード内で表現力を高めることができます。帯域外のパラメータ（Contract.Requires）のためにそれは直接でした。そうでない場合は、Contract.AssertまたはContract.Assumeは一般的な状態をチェックでき、メソッドを終了したときの状態の "保証された正確さ"はContract.Ensuresを使って表すことができます。 Invariantsは、常にその状態を保持しなければならないことを表明します。
• そして、スタティックチェックでは、コードをビルドするときにこれらのコントラクトを強制することができます。これにより、ランタイムを待たずにデザインタイムやコンパイル時間の警告でバグを拾うことができます。コンプライアンス違反を探すためにContinuous Integrationに契約チェックを追加することができます。

1つの警告：あなたが意図的に契約に違反するユニットテストを書くしようとしている場合、あなたはContractExceptionに対処する必要があるかもしれない - ジョンスキートはこのよくhereを説明します。例えばテストのセットアップでContract.ContractFailed handlerをハンドラに配線し、ハンドラにSetHandledを呼び出してから、あなたのUTで捕捉してアサートできるパブリック例外をスローします。