ブレークポイントを使用してデバッグしていて、アサート呼び出しを実現していますか?私はそれが単体テストのためだけだと思った。ブレークポイント以上の機能はありますか?ブレークポイントを作成できるので、なぜAssertを使用する必要があるのですか?
デバッグコンパイルでは、 Assert
はブール条件をパラメーターとして受け取り、条件がfalseの場合にエラーダイアログを表示します。条件が真の場合、プログラムは中断することなく続行します。
Releaseでコンパイルする場合、すべての Debug.Assert
は自動的に除外されます。
から コード完了
8防御的なプログラミング
8.2アサーション
アサーションとは、開発中に使用されるコード(通常はルーチンまたはマクロ)であり、プログラムが実行中に自身をチェックできるようにします。アサーションが真である場合、それはすべてが期待どおりに動作していることを意味します。 falseの場合、それはコードで予期しないエラーを検出したことを意味します。たとえば、顧客情報ファイルのレコードが50,000個を超えないとシステムが想定する場合、プログラムには、レコード数が50,000以下であるというアサーションが含まれる場合があります。レコードの数が50,000以下である限り、アサーションはサイレントになります。ただし、50,000件を超えるレコードが検出されると、プログラムにエラーがあると大声で「アサート」します。
アサーションは、大規模で複雑なプログラムや信頼性の高いプログラムで特に役立ちます。プログラマーは、不一致のインターフェースの仮定、コードが変更されたときに忍び寄るエラーなどをより迅速にフラッシュできます。
通常、アサーションには2つの引数が必要です。1つは想定される仮定を記述するブール式で、もう1つはそうでない場合に表示するメッセージです。
(…)
通常、実稼働コードでアサーションメッセージをユーザーに見せたくないでしょう。アサーションは主に開発およびメンテナンス中に使用されます。アサーションは通常、開発時にコードにコンパイルされ、本番用のコードからコンパイルされます。開発中、アサーションは矛盾した仮定、予期しない条件、ルーチンに渡された不適切な値などを洗い流します。実稼働中にアサーションがシステムパフォーマンスを低下させないように、コードからコンパイルされます。
変数をチェックするためにコードの小さな行ごとにブレークポイントを作成する必要はありませんが、特定の状況が存在する場合、何らかのフィードバックを取得したい場合に使用する必要があります:
Debug.Assert(someObject != null, "someObject is null! this could totally be a bug!");
Assertはまた、MicrosoftのUIデザインスキルをくすぐる別の機会を提供します。つまり、3つのボタンを備えたダイアログ、中止、再試行、無視、およびそれらをタイトルバーで解釈する方法の説明です!
Assertを使用すると、コードに条件(postまたはpre)が適用されることをアサートできます。これは、意図を文書化する方法であり、意図が満たされない場合にデバッガーにダイアログで通知させる方法です。
ブレークポイントとは異なり、Assertはコードと共に使用され、意図に関する詳細を追加するために使用できます。
Assertは、テストとリリースの間で個別のメッセージング動作を提供するのに役立ちます。例えば、
Debug.Assert(x > 2)
リリースビルドではなく「デバッグ」ビルドを実行している場合にのみ、ブレークがトリガーされます。この動作の完全な例があります here
まず、Assert()
メソッドはTrace
およびDebug
クラスで使用できます。Debug.Assert()
は、デバッグモードでのみ実行されています。Trace.Assert()
は、デバッグおよびリリースモードで実行されています。
以下に例を示します。
int i = 1 + 3;
// Debug.Assert method in Debug mode fails, since i == 4
Debug.Assert(i == 3);
Debug.WriteLine(i == 3, "i is equal to 3");
// Trace.Assert method in Release mode is not failing.
Trace.Assert(i == 4);
Trace.WriteLine(i == 4, "i is equla to 4");
Console.WriteLine("Press a key to continue...");
Console.ReadLine();
このコードをデバッグモードで実行し、次にリリースモードで実行します。
デバッグモード中にコードDebug.Assert
ステートメントが失敗すると、アプリケーションの現在のスタックトレースを示すメッセージボックスが表示されます。 Trace.Assert()
条件がtrue (i == 4)
であるため、これはリリースモードでは発生しません。
アサーションは、デザインバイコントラクト(DbC)で大きく機能します。これは、私が理解しているように、Meyer、Bertandによって導入/承認されました。 1997.オブジェクト指向ソフトウェアの構築。
重要な機能は、副作用を発生させてはならないことです。たとえば、ifステートメントを使用して例外を処理したり、別のアクションを実行したりできます(防御プログラミング)。
アサーションは、契約の事前/事後条件、クライアント/サプライヤーの関係を確認するために使用されます-クライアントは、サプライヤーの事前条件が満たされていることを確認する必要があります。 £5を送信し、サプライヤーは事後条件が満たされていることを確認する必要があります。 12本のバラを届けます。 (クライアント/サプライヤーの簡単な説明-受け入れを減らしてより多くを提供できますが、アサーションについてです)。 C#では、リリースコードに使用できるTrace.Assert()も導入されています。
質問に答えるために、彼らはまだ有用ですが、コードに複雑さ+読みやすさを加え、維持するのが困難です。まだ使用する必要がありますか?はい、すべて使用しますか?おそらく、そうではない、またはMeyerが説明する程度までではありません。
(この技術を学んだOU Javaコースでさえ、簡単な例を示しただけで、残りのコードはほとんどのコードでDbCアサーションルールを強制しませんでしたが、プログラムを保証するために使用されると想定されていました正確さ!)
私が考える方法はDebug.Assertは、メソッドの呼び出し方法に関するコントラクトを確立する方法であり、(型だけでなく)パラメーターの値に関する詳細に焦点を当てています。たとえば、2番目のパラメーターでnullを送信することになっていない場合、そのパラメーターの周りにAssertを追加して、それを行わないようにコンシューマーに指示します。
誰かがあなたのコードを骨抜きのように使用することを防ぎます。しかし、それはまた、その骨の折れた方法で本番環境を通り、顧客に不快なメッセージを伝えないようにします(リリースビルドをビルドすると仮定します)。