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