NUnit v3テストフレームワークの最初のベータバージョンが最近リリースされました。 とりわけ、このバージョンはテストの並列実行を実装します（ほぼ「すぐに使用可能」）。 1つの実際のプロジェクトでこれがどのように機能するかを確認することにしましたが、nunitの新しいバージョンは以前のバージョンで使用されていたものの一部を
サポートしていません 。 特に、ExpectedException属性の代わりにAssert.ThorwsまたはAssert.Thatを使用することをお勧めします。
このベータ版のリリースに関係なく、プロジェクトの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用のエージェントモルダープラグイン