Nunit: AssertionExceptionをキャッチすると、3.10以降のテストに失敗します。

あなたのテストは、NUnitがどのように機能するかについての2つの命題をテストしています。

1. すべてのアサーションの失敗がAssertionExceptionをスローすること。
2. 例外をキャッチすると、エラーが報告されなくなります。

たまたま、最初のステートメントはほとんど真ですが、複数のアサートブロック内に保持されないか、警告を発行します。 2番目はまったく真実ではありません。 例外をキャッチするまでに、障害はすでに記録されています。 これはNUnitの内部動作の変更であり、これらの例外をキャッチしている場合にのみ観察できます。 私は、それが単なる実装の偶然であるため、何年もの間、その動作に依存しないように人々に言ってきました。

サンプルコードは、発生した問題を示すことのみを目的としていることを理解しています。 例外をキャッチするために実際に何をしようとしているのか、例を挙げていただけますか？ 私たちはあなたがより良い解決策を見つけるのを手伝うことができると確信しています。

このような短い通知で私に戻ってきてくれてありがとう。 私は物事がまだ不安定なときにメカニズムを使用します。 そのため、ソフトウェアが正しく機能しない場合があります。 これらの場合、私はこれを開発者に報告します。 それまでの間、この不安定な動作を回避するためにテストを拡張しました。 したがって、この問題で失敗するのではなく、テストに合格します。

これにWarn.If（）メソッドを使用しようとしましたが、これにより、テストエクスプローラーで結果が「TestSkipped」に設定されます。 これにより、テストがまったくスキップされないため、レポートの失敗が発生します。 そのため、代わりにアサーションキャッチを実装し、警告をトレースすることを選択します。 私は知っています、望ましくありませんが、それはかなりうまくいきました。 少なくとも最後の更新まで。

この変更が意図的なものかどうか知りたいのですが、その場合は変更する必要があります。

Warn.Ifは正常に機能します...テストエクスプローラーでは__except__。 😢問題は、テストエクスプローラーが合格と不合格を認識しているが、警告は認識していないことです。 警告結果ステータスを実装するまで、警告結果を理解できるものに変換する必要がありました。 FWIWは、結果の状態が不確定である場合にも同様の問題があります。

私たちが行った変更は意図的なものであり、長い間計画されてきました。 例外にあまり依存したくないので、テストを停止しない方法で、アサーションの結果（最終的には合格したものも含む）を報告したいと思います。 あなたのようなユーザーへの影響を軽減するためにいくつかの変更を加えましたが、これは軽減の余地がないようです。

不安定なテストがある場合、長年の標準はそれらを無視することでした。 残念ながら、多くのチームは「無視されたテストを無視」します。その場合、それはそれほど良い選択ではありません。 警告を真剣に受け止めるようにチームをトレーニングできる場合（実際には、エラーや失敗とほぼ同じくらい真剣に）、警告ステータスを使用してフレークネスを強調することができます。 もう1つの可能性は、UntilプロパティでIgnoreを使用することです。これにより、特定の日付までに修正されない場合、失敗に変わります。

ところで、私がチームを指導するとき、私は通常、無視されたテストのBig VisibleDisplayを継続的に更新しています。 ほとんどのチームでは、誰が何の責任者かを誰もが知っているので、不安定なテストの責任者を実際に呼び出す必要はありません。 誰もが問題を見ると、修正される傾向があります。

@svanimpelenは、Retry属性を使用してみましたか？ それはあなたがそれらを通過させるためにそれらを数回実行することを可能にします。

エクスプローラーでテストがスキップされる結果となる警告については、現在サポートされているMSTestの限られた数よりも多くの結果状態を指定できるようにすることについて、ビジュアルスタジオチームと話し合いました。 彼らはそのアイデアを気に入っているので、将来的には改善が見られることを願っています。 それまでは、スキップして苦しむ必要があります。 とはいえ、スキップすると警告が表示されます。 警告を非常にわかりやすくしたいと思います😄

非常に多くのメソッドが文書化されているため、APIは失敗時にAssertionExceptionをスローします。

https://github.com/nunit/nunit/blob/d03e93c8f25170a8ff48e80863a3fe6fd294613a/src/NUnitFramework/framework/Assert.That.cs#L40 -L43

このドキュメントとNUnitの長年の動作は、3.10の重大な変更を構成しませんか？
何かが足りない場合を除いて、少なくとも今は正しくないドキュメントを削除する必要があります。

複数のアサーションブロックを導入したため、ドキュメントが誤解を招く可能性があることに同意します。 とはいえ、この場合はAssertionExceptionがまだスローされていますが、違いは、例外がキャッチされたにもかかわらず、テストがVisualStudioで失敗として報告されるようになったことです。 私はそれを重大な変化とは見ていません。 ユーザーは、たまたま機能した文書化されていない動作に依存していました。 私にとって、それは、ユーザーがたまたまテストをアルファベット順に実行してテストを順序付けているという事実に依存しているのと同じです。

おそらくドキュメントを更新する必要があります。 例外のスローに関する情報を削除し、代わりに、誤った条件がテストに失敗したことを示すことができます。 および/または、例外がマルチアサートブロックでスローされないと言うことができますか？ 個人的には、スローされる例外のタイプは内部の詳細だと思うので、最初のオプションを好みます。

そうだと思います。 例外の使用がどこかに文書化される場合、それは内部のwikiセクションにある可能性があります。

メソッドのドキュメントに例外がスローされると記載されている場合、例外は呼び出しサイトでキャッチできると明確に言っていると思います。 C＃は例外をチェックしておらず、XMLドキュメントはメソッドコントラクトのその部分をどのように伝達してきたかを示しています。 「throwsX」という言葉は常にメソッドがそれをキャッチしないことを意味していることを私が知っている限り、私はまだ他の人がそれをどのように取っているのか少し心配しています。 たぶん、安全のためにウィキの重大な変更メモですか？

XMLドキュメントからAssertionExceptionへのすべての参照を削除し、AssertionExceptionを使用しないように警告するwikiページを作成するというアイデアが好きです。

💭 AssertionExceptionキャッチすることが常にバグである場合、そのタイプを内部にすることを検討できますか？

@ jnm2。

XMLドキュメントの重要性については同意しますが、実際のところ、これらのドキュメントは、これまで契約の一部を伝達してきた方法ではありません。 私は実際にあなたがそれを提案する最初の人かもしれないと思います、そしてそれは良い考えだと思います。

しかし、そのように考え始めると、多くの誤ったコメントを変更する必要があることを認識しておく必要があると思います。 これらのドキュメントの変更のそれぞれを重大な変更として扱うことはできないと思います。 ケースバイケースで、根本的な行動の変化を破壊的なものとして合理的に扱うことができますが、それは異なります。 ドキュメントの変更が壊れてはいけません。

これは、重大な変更のリストに何を含めるべきかという問題を提起します。 あなたの過去のコメントを理解していれば、ユーザーを傷つける可能性のあるものは何でも文書化したいと思う傾向があると思います。 多くのユーザーを壊すと思われることを文書化することを好みます。

これが私が違いをどのように見ているかです-他の人は同意しないかもしれません...__壊れるかもしれないすべてのもの__を文書化することは私にとってCYAのようなにおいがします。 すべてを文書化すると、次のように言うことができます...「ほら、私たちはカバーされています。」 重要と思われるものだけを文書化すると、間違って謝罪しなければならないリスクがありますが、平均的なユーザーは一連の変更をはるかに理解しやすくなります。 私は後者が好きです。

アサーション例外をキャッチしても安全な場合があります。 たとえば、TestExecutionContextを使用せずに直接テストを実行しても安全であるように、しばらく前に変更を加えました。 例外を内部にすると、それを破ります。 実際、私はそれを壊して幸せでしたが、チームは私たちがすべきではないことに同意したので、私はそれを修正しました。 あなたはただあなたが何を壊しても構わないと思っているかを決める必要があります。 その修正は、メソッドを呼び出すコードではなく、テスト自体の内部で例外をキャッチすることを扱う現在の問題を__not__処理しました。

テストでAssertionExceptionをキャッチすることは、私が古典的な「匂い」と呼ぶものです。 おそらく間違っていますが、特定のケースを調べて知る必要があります。 「NUnitの内部に関する詳細な知識がない限り、AssertionExceptionのキャッチはエラーである可能性が高いです。適切な動作を保証するために、テストの結果を変更しようとせず、やりたいことを実行した後に例外を再スローする必要があります。それと。" しかし、私はまだそのような情報がXMLドキュメントや一般ユーザードキュメントに属しているとは思いません。 内部セクションにページとして配置します。

ところで、私の過去の経験では、何かを文書化し、それを使用しないように人々に指示すると、使用量が増加します。 😄

良い点、ありがとう！ 部分的にはCYAの観点から考えていると思います。 もう1つの要素もあります。それは、ライブラリの利用者として、自分のコードで悪い仮定を探すことができるように、すべての重大な変更について教えていただければ幸いです。 特に、コンパイラが気付かないこのような変更の場合。 よろしくお願いしますので、ある程度ユーザーに投影します。

ドキュメントの修正を追跡するために新しい問題を開始する必要がありますか？

なぜ新しいのですか？

タイトルは、修正するのではなく、回答済みの質問として閉じるもののように見えます。 通常、タイトルを変更し、この問題を使用してドキュメントの変更を追跡しますか？

私が通常行っていることは、問題を確認して分類することです...この場合はドキュメントの問題です。 確かに、私たちは最初に考えられるバグとしてそれについて議論するのに本当に長い時間を費やしました。 これはプロジェクト管理の質問であり、実際には私の範囲外です。

私が言っているのは、論理的で一貫性のあることをすることです。 😄バグではないのでこれを閉じることはオプションです。 しかし、それは苦情を解決策から切り離します。 ドキュメントのバグとして再分類し、場合によってはタイトルを編集するときに説明コメントを書くと、苦情のある解決策が維持されます。 いずれにせよ、Doneの問題のタイトルはリリースノートに記載されているので、何が起こったのかを表現する必要があります。

例外をキャッチするために実際に何をしようとしているのか、例を挙げていただけますか？ 私たちはあなたがより良い解決策を見つけるのを手伝うことができると確信しています。

3.10にアップグレードした後、テストが失敗し始めたため、現在同じ問題に直面しています。 今ここに私の問題があります：
カスタムテストアサーションメソッドがあります。 それらは内部的にNUnit.Assertを呼び出します。 これらのアサーションメソッドをテストして、失敗すると予想されるときに実際に失敗することを確認します。
現在、私のテストはAssertionExceptionをキャッチして、カスタムアサーションメソッドがテストの失敗を引き起こすことを確認していますが、アップグレード後、上記の理由により、これらのテストはすべて失敗し始めます。

3.10でそれらをテストするための推奨される方法は何ですか？

ありがとう。

最も簡単なアプローチは、Assert.Throwsを使用して、自分で行うのではなく、例外をキャッチすることです。 Assert.Throwsは、NUnitの内部を理解し、障害が報告されないようにします。

先日、通知でこれを見て、あまり考えていませんでした。 ただし、ロジック内で「Assert.That」を実行する私のライブラリプロジェクトを更新します（これはテストヘルパーフレームワークです。特に、EFコンテキストとエンティティを手動でコーディングし、対応するデータベースをコーディングするときにEFの永続性をテストする簡単な方法を提供します。手作業での移行（またはFluentMigratorのようなものを使用）-つまり、呼び出し元に代わってアサーションを実行することになっています）、テストが失敗するはずの場所で失敗するようになりました-特に1つのテストはアサーションです特定の条件でテストが失敗するはずですが、「キャッチ」は通常どおり機能しなくなったため、これらのテストは実際に合格しているものの、失敗として報告されます。

したがって、適切なNUnitアサーションをスローできないか、ユーザーの面倒なタスクを実行してテスト開発を迅速化することを目的としたライブラリコードでAssert.Thatを使用できないと思いますか？

私は、例外がユーザーによって消費されない場合、ユーザーがスローできるようにすべきではないという以前の声明に同意します。 ただし、コンシューマー用にAssert.Thatコードを配置し、コードが想定どおりに失敗するために失敗することをテストするという問題は解決されません。nunitアサーションで失敗します。

おそらく、結果APIのいくつかを製品化する必要がありますか？

@fluffynuts私があなたを正しく理解していれば、 catch句は、ユーザーライブラリのコードではなく、テストコードにあります。 （ユーザーライブラリにもある場合は、それについて話すことができますが、問題は少し異なります。）

もちろん、NUnitにはそれ自体のテストがあるため、この変更が行われたときにまったく同じ潜在的な問題が発生しました。 当然、私たちは独自のテストを変更して、合格し続けました。 あなたは同じことをすることができます。

防衛の第一線はAssert.Throwsです。 失敗動作をテストするほとんどの場合、 try / catch(AssertionException)をAssert.Throws<AssertionException>直接置き換えることができます。 内部的にAssert.Throwsは、使い捨ての分離されたTestExecutionContext Assert.Throws作成するため、実際のテスト結果は、テストしているエラーによって汚染されません。

場合によっては、独自の分離されたコンテキストを作成する必要があります。 Assert.Throwsコードを調べることで、その方法を確認できます。

ただし、NUnit独自の障害テストの多くは、実際には異なるアプローチを使用しています。 独自のテストプログラムによって実行されるテストを含む別のアセンブリがあります。 結果を取得して調べることができます。 これはより多くの作業ですが、NUnitに関する実装の詳細をテストに入れすぎないようにします。 これを行うほとんどのメソッドは、テストユーティリティアセンブリにあります。 @ jnm2が言及しているのはそれだと思います。

ご不明な点がございましたら、投稿するか、オフラインでご連絡ください。

情報をありがとう。 はい、アサーションはテストコード内に含まれています。 Assert.Throwsは通常このトリックを実行しますが、問題の特定のテストは、データベースから取得する日時値のテストを許可するデルタが「低すぎる」ライブラリコードを実行します。 ほとんどの場合、これでlocaldbに発生するドリフトは1ミリ秒ですが、ドリフトが大きくなることもあります。このテストは、「時々」発生することを表明することを目的としています。 そのため、現時点では、コードを4つの並列スレッドで10回実行し、少なくとも1つの失敗が予想されます。 Assert.Throwsは、残念ながら、この場合は決定論的すぎるため、nunit例外（またはライブラリコード内のAssert）の使用を停止するか、皆さんが使用するfuを学習する必要があります。 ポインタをいただければ幸いです。必要に応じて、オフラインで実行できます。

ええと、私が見つめていたAsyncVoidVerificationScopeのメッセージポンプテストの失敗は、@ fluffynutsが抱えている問題と気づきました。 実際には、[アセンブリ：RestoreSynchronizationContext] ITestActionではなく、NUnit3.10のアップグレードが原因です。 一度に複数のことをしている間、それらを無視する権利を私に提供します。 ：NS

とにかく、私は何をしたいかのように見えますが、私の中で、デリゲートの呼び出しをラップでusing (new TestExecutionContext.IsolatedContext())と同じようにAssert.Throwsません。

ただし、 Assert.ThrowsとAssert.ThrowsAsyncは、非同期デリゲートを呼び出す前に分離されたコンテキストを確立しません。 どうしてこれなの？

@fluffynutsずっと前に、私が最初にAssert.Catch書いたとき、それは単に例外をキャッチしただけで、例外がスローされなくてもエラーを生成しませんでした。 残念ながら、それは変更され、 Assert.Throws相当する「ニュートラル」はなくなりました。 ただし、1つ書くことはできます。 これは、 Assert.Throwsのコードに基づくテストされていないバージョンです。 同期コードのみを処理しますが、 Assert.Throws追加コードを使用して、非同期用に簡単に拡張できます。

`` `C＃
public static void Exception SafelyCatchAnNUnitException（TestDelegate code）
{{
例外caughtException = null;

using (new TestExecutionContext.IsolatedContext())
{
    try
    {
        code();
    }
    catch (Exception ex)
    {
        caughtException = ex;
    }

    return caughtException;
}

}
`` `

このメソッドは、スローされた例外を返し、NUnitのassertメソッドによって残されたエラーの残りをクリーンアップします。 例外がスローされない場合は、nullを返します。

コードの上位レベルでIsolatedContext()を使用して、実際のテスト結果を取得することもできます。 これにより、例外を参照せずに、テスト結果のレベルで完全にテストできます。 このタイプのテスト用のライブラリを作成することを考えました。これは、NUnitが現在独自のテストを実行する方法よりも優れていると思います。