問題タブ [assertions]

私は、CSの学位を取得して卒業し、約1年間プロのソフトウェアエンジニアを務めています。私はC++とCでアサーションについてしばらく知っていましたが、最近までC＃と.NETにアサーションが存在することをまったく知りませんでした。

私たちの製品コードにはアサートがまったく含まれていません。私の質問はこれです...

プロダクションコードでAssertsの使用を開始する必要がありますか？もしそうなら、その使用はいつ最も適切ですか？するほうが理にかなっていますか

また

「パフォーマンス アサーション チェック」システムの設計に関する意見はありますか?

アイデアは、開発者が自分のコードについていくつかのアサーションを作成し、これらを使用してコードのパフォーマンスの進化をテストするというものです。そのようなシステムでの経験は何ですか？

私の現在のブロックは、「指定された言語 (指定されたログまたはランタイム インストルメンテーションに対してチェックされる) で記述されたこれらのアサーションを、CLR、実行可能なアセンブリまたはバイトコードなどに変換するより良い方法は何ですか?」です。

現在、仕様を解析してデータ構造に保持するパーサーを作成しました。

メソッドが 1 回だけ呼び出されると主張したい。RhinoMocks 3.5 を使用しています。

これが私がうまくいくと思ったものです：

GetMeMyThing()2 回目の呼び出しでこのテストが失敗するようにしますsource.GetSomethingThatTakesALotOfResources()。

SamlAssertion のインスタンスを作成し、それに認証ステートメントと属性ステートメントを追加しました。HTTP ポストを実行できるように XML を出力したいのですが、すべてのアサーションが出力されているわけではありません。私は何を見逃していますか（それは骨の折れるものだと確信しています）？

私が使用しているコードは次のとおりです。

しかし、返されるのはこれだけです:

私は自分の Assert.AreEqual を多くの異なるクラスに拡張するのが大好きです。既知のクラスはもちろん CollectionAssert ですが、ImageAssert、 XmlAssert など、さらにいくつか考えられます。

独自の Assert クラスを作成しましたか? そして、どんな新しいものを作りたいですか？

私は以前、主任アーキテクト/開発者の何人かがさまざまなプロジェクトでアサーションを使用しないことを義務付けていた会社で働いていました。アサーションは定期的にコードから削除され、例外に置き換えられていました。

正しいコードを書く上で非常に重要だと思います。そのような義務がどのように正当化されるかを誰かが提案できますか? もしそうなら、アサーションの何が問題なのですか?

驚いたことに、私はこの主題について SO に関する以前の質問を 1 つしか見つけることができませんでした。私のアプローチについて、コミュニティの「信任投票」(またはそうでない!) を取得したいと思います。

私がそれを見る方法は次のとおりです。

• Debug.Assertあなたが期待することが真実であることを述べるために使用します。これは、環境を完全に制御している場合に使用されます。たとえば、事前条件と事後条件を検証する方法です。
• 例外的な状況が発生した場合は例外を使用します。ファイル、データベース、ネットワークなどの外部リソースを扱うのは簡単です。しかし...

次のシナリオでは、少し曖昧になります。これは説明のみを目的とした不自然な例であることに注意してください。

パブリック プロパティ MyMode と method を持つクラス MyClass があるとしますGetSomeValueForCurrentMode()。MyClass は、他の開発者が使用するライブラリで出荷 (リリース ビルド) されることを意図したものと考えてください。

MyMode は、このクラスの外部ユーザーによって更新されることを期待しています。現在、GetSomeValueForCurrentMode()次のロジックがあります。

ここで私が得ているのは、MyClass のユーザーがそれを無効な状態のままにしたということです。だから何をすべきか？

デフォルトでは、私たちDebug.Assertまたはthrow new InvalidOperationException（または他の）べきですか？

クラスのユーザーを信頼してはならないという 1 つのマントラがあります。Debug.Assert を選択し、MyClass をリリース ビルドとしてビルドした場合 (それによってデバッグ アサートを削除した場合)、クラスのユーザーは、クラスを無効な状態のままにしておいたという有用な情報を取得できません。しかし、それは、完全に制御できないことが起こった場合にのみ例外をスローするという別のマントラに反するものです。

私はこれについてぐるぐる回っていることに気づきました - 決定的な「正しい」答えがないように見えるプログラミングの議論の1つです。それでは投票に入れましょう！

編集:関連する SO の質問 (アサーションまたは例外を使用した契約による設計? ) でこの応答に気付きました:

経験則として、自分自身のエラーをキャッチしようとするときはアサーションを使用し、他の人のエラーをキャッチしようとするときは例外を使用する必要があります。つまり、例外を使用して、パブリック API 関数の前提条件を確認し、システムの外部にあるデータを取得するたびに確認する必要があります。システム内部の関数またはデータにはアサートを使用する必要があります。

私にとって、これは理にかなっており、以下に概説する「アサートしてからスローする」手法と組み合わせることができます。

考えを歓迎します！

Visual Studio で C# プロジェクトのデバッグ定数を定義すると、アサーションが評価され、失敗したときにメッセージ ボックスが表示されることを確認できます。しかし、アサーションを評価して表示するかどうかを実際に実行時に CLR に決定させるフラグ、属性は何ですか。DEBUG が定義されている場合、アサーション コードは IL で終了しませんか? それとも、アセンブリの DebuggableAttribute のDebuggableAttribute.DebuggingModesフラグが重要なポイントですか? もしそうなら、それのどの列挙値が存在しなければなりませんか? これは内部でどのように機能しますか?