問題タブ [assert]

Windows上のVisualC++でアサーションが失敗すると、デバッガーが停止してメッセージを表示し、続行できるようにします（または、デバッグセッションが実行されていない場合は、Visual Studioの起動を提案します）。

Linuxでは、assert（）のデフォルトの動作は、エラーを表示してプログラムを終了することのようです。すべてのアサートはマクロを通過するため、シグナルを使用してこの問題を回避しようとしました。

しかし、GDB（KDevelopを介して）は正しいポイントで停止しますが、シグナルを超えて続行できないようです。GDB内でシグナルを手動で送信すると、GDBもデバッグされたプロセスも制御できず、ハングしたままになります。

この質問は近いですが、それでも私が望むものではありません。2つのBeanオブジェクトが同等であることを一般的な方法で主張したいと思います。そうでない場合は、ブール値の「等しい」または「等しくない」の代わりに、違いを説明する詳細なエラーメッセージが必要です。

Canvas上でデータを移動するWPFアプリケーションがあります。問題は、フリークのようにマウスでデータを移動しようとしたときに始まりました。

アクションのシーケンスは次のとおりです。

• キャンバス上のMouseMoveがトリガーされます
• MouseMoveで、いくつかのデータを変更します
• Trace.Assertが失敗します。デバッガーは壊れませんし、メッセージボックスも壊れません
• 別のMouseMoveがトリガーされます
• データが再び変更されます
• コレクションの再入可能性チェックが原因で例外がスローされます。デバッガーはそこで壊れます。[アサート]メッセージボックスは表示されませんでした。

ここでの大きな問題は、アサーションに戻ることができるということですが、それはアサーションが失敗したときのデータではなく、最後に変更されたデータです...したがって、基本的にそれを正しくデバッグすることはできません。

これが最初のMouseMoveから始まるスタックトレースです（ShowMessageBoxAssertとそれがまだ続くという事実に注意してください...）：

問題は、なぜこれが発生する可能性があるのか​​、そしてアサート時にそれを中断させるために何をすべきかということです。

おそらくデバッグのために例外を使用することを考えましたが、それは本当に私が必要としている主張です。デバッグのために常に例外に変換する必要なしに、他のすべてのアサートについても考えています...

短い質問、なぜAssert.AreEqual(1.0, double.NaN, 1.0)合格するのですか？一方、Assert.AreEqual(1.0, double.NaN)失敗します。

これはMSTest（Microsoft.VisualStudio.QualityTools.UnitTestFramework）のバグですか、それともここに何かが欠けていますか？

よろしく、エギル。

更新：おそらく、私の質問の背後にある理由は、NaNまたは（+/-）Infinityである線形代数行列演算の結果のために残念ながら合格した単体テストがたくさんあることです。単体テストは問題ありませんが、実際のまたは/および期待されるがNaNまたはInfinityの場合、デルタを含むdoubleのAssert.AreEqualは合格するため、テストしたコードは正しいと信じられました。

Flash ムービーは、さまざまなアサートを含む別のムービーをロードします。つまり、「アクション スクリプト用にエクスポート」設定が設定されたライブラリ内のムービー クリップです。

これらすべてのエクスポートされたアサーションのクラス名のリストを、それらをロードするムービー内から特定する方法はありますか?

「安定」し、テストおよび本番環境に移行されたコードにTrace.Assertandステートメントを残すことは賢明ですか?Debug.Assert

もしそうなら、これらのアサーションステートメントはどのように役立ちますか? Guard クラスなどで例外条件をチェックし、必要に応じて例外を発生させるだけで十分ではないでしょうか。

Java ロガーを呼び出してステータスを報告するテスト対象のコードがいくつかあります。JUnit テスト コードで、このロガーで正しいログ エントリが作成されたことを確認したいと思います。次の行に沿ったもの：

これは、特別に適合されたロガー (またはハンドラー、またはフォーマッター) を使用して実行できると思いますが、既存のソリューションを再利用することをお勧めします。(そして、正直なところ、ロガーから logRecord を取得する方法は私には明確ではありませんが、それが可能であると仮定してください。)

これは、入力がlist/ tuple-であるが、ではないことを確認するために私が通常行うことstrです。関数が誤ってオブジェクトを渡すバグに何度も遭遇したためstr、ターゲット関数はそれが実際にはまたはであるとfor x in lst想定します。lstlisttuple

私の質問は：これを達成するためのより良い方法はありますか？

C および C++ では、プログラムにエラーを書き込んで終了するassert、非常に重いルーチンです。stdout私たちのアプリケーションでは、assert のはるかに堅牢な代替を実装し、独自のマクロを与えました。マクロを置き換えるためにあらゆる努力が払われましたが、再導入できるassert方法はまだたくさんあります(たとえば、内部のサードパーティ ライブラリ、ナイーブ インジェクションなどから)。assert

の使用を減らしたり、制限したり、根絶したりする方法について何か提案はありassertますか? 最良の答えは、コンパイラがキャッチできるものであり、現在のようにコード ベースを子守する必要はありません。

Go言語の作成者は次のように書いています。

Goはアサーションを提供しません。それらは紛れもなく便利ですが、私たちの経験では、プログラマーは適切なエラー処理とレポートについて考えることを避けるためにそれらを松葉杖として使用しています。適切なエラー処理とは、サーバーがクラッシュするのではなく、致命的でないエラーの後で動作を継続することを意味します。適切なエラー報告とは、エラーが直接的かつ的を射たものであることを意味し、プログラマーが大きなクラッシュトレースを解釈する手間を省きます。正確なエラーは、エラーを見たプログラマーがコードに精通していない場合に特に重要です。

これについてどう思いますか？