このベータ版のリリースに関係なく、プロジェクトの1つで、他のすべてのnunitメソッドと属性の代わりにAssert.Thatモデルを使用し始めました。
猫の下では、ExpectedException属性をAssert.Thatモデルに変換した経験はほとんどありません。
結局のところ、私がnunit v3で翻訳することを選択したテストプロジェクトです。 ExpectedException属性の使用が100以上含まれています。 当然、移行プロセスを何らかの形で自動化したかったのです。
興味深いことに、以前にExpectedException属性が非常に成功しているようであれば、最近いくつかの問題が発見されました。
たとえば、次のテストでは、どの行で例外が予想されるかはあまり明確ではありません。 通常は後者ですが、以前のメソッドが同じ例外をスローした場合、テストは正しく機能しません。 いずれにせよ、ある種の不確実性があります。「結局のところ、例外的な状況が予想される場所です」。
[Test] [ExpectedException(typeof(ArgumentException))] public void TestExpectedException() { foo1(); foo4(); foo1(); }
干渉するもう1つの小さなことは、「コードカバレッジ」に関するレポートです。 dotCoverを実行し、レポートを調べて確認してください：
しかし、それをAssert.Thatに置き換えることはまったく別の問題です：100％のカバレッジを取得します。
「手」を変更するのは簡単すぎる方法だと気づいた後:)、nunitコンストラクトをAssert.Thatモデルに変換するのに役立つリゾルバー用のプラグインを作成することにしました。
そして、テストプロジェクトの翻訳に必要なものから始めました。
最初は非常に簡単でした：
[Test] [ExpectedException] public void TestShortExpectedException() { foo1(); foo2(); foo1(); }
に翻訳
[Test] public void TestShortExpectedException() { foo1(); Assert.That(foo2, Throws.Exception); foo1(); }
より複雑な例は、匿名メソッドの使用です。
[Test] [ExpectedException] public void TestExpectedExceptionWithExpressions() { double i = 2 + getNumber(); }
[Test] public void TestExpectedExceptionWithExpressions() { Assert.That(() => { double i = 2 + getNumber(); }, Throws.Exception); }
特定の予想されるタイプには、 Throws.TypeOfの実装が必要でした
[Test] [ExpectedException(typeof(ArgumentException))] public void TestExpectedException() { foo1(); foo4(); foo1(); }
[Test] public void TestExpectedException() { foo1(); Assert.That(() => { foo4(); }, Throws.TypeOf<ArgumentException>()); foo1(); }
例外的な状況のメッセージの予想テキスト（またはロシア語の「メッセージメッセージ」）では、 .And.Messageを追加する必要がありました。
[Test] [ExpectedException(typeof(NotImplementedException), ExpectedMessage = "customer message")] public void TestExpectedExceptionWithCustomerMessage() { foo4("customer message"); }
[Test] public void TestExpectedExceptionWithCustomerMessage() { Assert.That(() => { foo4("customer message"); }, Throws.TypeOf<NotImplementedException>().And.Message.EqualTo("customer message")); }
すべての設計がまだサポートされているわけではありません。たとえば、 MathTypeは正しく変換されません。
[Test] [ExpectedException(typeof(NotImplementedException), ExpectedMessage = "customer message", MatchType = MessageMatch.Contains)] public void TestExpectedExceptionWithCustomerMessage() { foo4("my customer message"); }
Assert.IsNullOrEmptyおよびAssert.IsNotNullOrEmptyの構成を、プログラミングなしで実装しますが、 カスタムパターンのみで変換します。
カスタムパターンは強力な機能ですが、明らかに、複雑なデザインの場合、スムーズに機能しません。
アサート-設計はシンプルで、問題はありませんでした。
プラグインは「NUnit.That.Resharper.Plugin」と呼ばれ、そのベータ版は「Resharper-Manage Extensions」からダウンロードできます。
Resharperバージョン8.2でのみテスト済み。
現在、少数のデザインセットがサポートされています。
視覚的には、プラグインは次のように機能します。
目的の行を選択します
変換された式を取得します（ExpectedException属性が削除されます）
結論 ：
-Assert.Thatは、私にはかなり魅力的なモデルのように見えました。
-NUnit v3。 まだベータ版です（ドキュメンテーションは慎重に！）が、既にテストプロジェクトを試し、実際のプロジェクトを準備することができます。
-リゾルバー用のプラグインを記述する完全なサイクル（ テストと配布を含む ）は見た目ほど複雑ではなく、「一般的な」だけでなくローカルの問題を解決するために使用できます。
プラグイン開発の特性を理解するのを助けてくれたリシャーパーチーム（および個人的にmezastel ）に特別な感謝を申し上げます。 Resharper SDKを使用すると、テンプレートからVisual Studioプロジェクトを作成できるため、問題が大幅に促進されます。
参照：
-githubプロジェクトhttps://github.com/constructor-igor/NUnit.That.Resharper.Plugin
-ギャラリーのNUnit.That.Resharper.Pluginプラグインhttps://resharper-plugins.jetbrains.com/packages/NUnit.That.Resharper_v8.Plugin/
例とドキュメントへのリンク
-Resharper ReSharper DevGuideの開発者向けドキュメント。
-投稿「 ReSharperのプラグインを書く-それほど難しくない 」
-ReSharper用のエージェントモルダープラグイン