タグ付けされた質問 「assertions」

18
家系図ソフトウェアのサイクル
ロックされています。質問はトピックから外れていますが、歴史的に重要であるため、この質問とその回答はロックされています。現在、新しい回答や相互作用を受け入れていません。 私はいくつかの家系図ソフトウェア(C ++とQtで書かれた)の開発者です。私の顧客の1人がバグレポートを私にメールするまで問題はありませんでした。問題は、顧客には自分の娘を持つ2人の子供がいて、その結果、エラーのために彼が私のソフトウェアを使用できないことです。 これらのエラーは、処理されているファミリーグラフに関するさまざまなアサーションと不変条件の結果です(たとえば、サイクルを歩いた後、プログラムはXがYの父と祖父の両方になることはできないと述べています)。 すべてのデータアサーションを削除せずにこれらのエラーを解決するにはどうすればよいですか?



7
Assert.Throwsを使用して例外のタイプをアサートするにはどうすればよいですか?
Assert.Throws例外のタイプと実際のメッセージの表現をアサートするにはどうすればよいですか。 このようなもの: Assert.Throws<Exception>( ()=>user.MakeUserActive()).WithMessage("Actual exception message") 私がテストしているメソッドは、異なるタイプの同じタイプの複数のメッセージをスローし、コンテキストに応じて正しいメッセージがスローされることをテストする方法が必要です。

20
Debug.Assert()はいつ使用する必要がありますか?
私は約1年間プロのソフトウェアエンジニアとして、CSの学位を取得しています。私はC ++とCでアサーションについてしばらく知っていましたが、最近までC#と.NETにアサーションが存在することをまったく知りませんでした。 私たちのプロダクションコードにはアサートがまったく含まれておらず、私の質問はこれです... 製品コードでアサートの使用を開始する必要がありますか?もしそうなら、いつその使用が最も適切ですか?行う方が理にかなっていますか Debug.Assert(val != null); または if ( val == null ) throw new exception();

6
JUnitアサーションで配列を比較すると、組み込みの簡潔な方法ですか?
JUnitで2つの同じような型の配列に対して等しいアサーションを行うための簡潔で組み込みの方法はありますか?デフォルトでは(少なくともJUnit 4では)、配列オブジェクト自体でインスタンス比較を行うようです。 EG、動作しません: int[] expectedResult = new int[] { 116800, 116800 }; int[] result = new GraphixMask().sortedAreas(rectangles); assertEquals(expectedResult, result); もちろん、私はそれを手動で行うことができます: assertEquals(expectedResult.length, result.length); for (int i = 0; i < expectedResult.length; i++) assertEquals("mismatch at " + i, expectedResult[i], result[i]); ..しかし、もっと良い方法はありますか?
158 java  arrays  junit  assertions 


5
Eclipse:アサーションを有効にする
私はEclipse Galileoを実行しています。Eclipseでアサーションを有効にするにはどうすればよいですか? 他のサイトで提案されているように、私は引数を追加しようとしました:-ea。また、コンパイラーの準拠レベルをに変更してみました1.4。これらの提案はどちらも機能しませんでした。

8
Debug.Assertと例外のスロー
私は、アサーションの使用方法と使用時期に関する多くの記事(およびStackOverflowに投稿された他のいくつかの同様の質問)を読みましたが、それらをよく理解しています。しかし、それでも、Debug.Assert単純な例外をスローする代わりに、どのような動機で私を駆り立てるのか理解できません。つまり、.NETでは、失敗したアサーションに対するデフォルトの応答は、「世界を停止」してユーザーにメッセージボックスを表示することです。この種の動作は変更できる可能性がありますが、それを行うのは非常に煩わしく冗長であると思いますが、代わりに適切な例外をスローすることもできます。このようにして、例外をスローする直前にアプリケーションのログにエラーを簡単に書き込むことができ、さらに、アプリケーションが必ずしもフリーズするわけではありません。 それで、もしあるとすればDebug.Assert、明白な例外の代わりに使用する必要があるのはなぜですか?アサーションを本来あるべきではない場所に配置すると、あらゆる種類の「望ましくない動作」が発生する可能性があるため、私の見解では、例外をスローする代わりにアサーションを使用しても何も得られません。私に同意しますか、それともここで何か不足していますか? 注:「理論上」の違いは何なのか(デバッグとリリース、使用パターンなど)は完全に理解していますが、それを見ると、アサートを実行するのではなく、例外をスローした方がよいでしょう。プロダクションリリースでバグが発見された場合でも、「アサーション」を失敗させたいので(結局のところ、「オーバーヘッド」は途方もなく小さいので)、代わりに例外をスローした方がよいでしょう。 編集:私がそれを見る方法、アサートが失敗した場合、それはアプリケーションが何らかの破損した予期しない状態に入ったことを意味します。では、なぜ実行を続けたいのでしょうか?アプリケーションがデバッグバージョンとリリースバージョンのどちらで実行されているかは関係ありません。同じことが両方に行きます

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.