2017-10-24 7 views
0

履歴:nUnit 3.複雑な継承を持つテストがあります。 SetUpまたはOneTimeSetUpに特定のオブジェクトが作成されます。これらのメソッドは仮想です。このオブジェクトが閉じていない場合、リークが発生します。nUnit拡張モジュールは、テストと同じアセンブリ内にあります。

問題:オブジェクトがTearDownまたはOneTimeTearDownで破壊されていますが、SetUpまたはOneTimeSetUpが成功したときに、それらが唯一と呼ばれています。したがって、例外がTearDownまたはOneTimeTearDownのどこかで発生すると、リークが発生します。私が言及したように、複数の継承レベルが存在するため、異なるクラスの異なるスタックフレームで、例外とクリティカルオブジェクトの作成が行われる可能性があります。

私がしたいこと:初期化が完了してクリティカルなオブジェクトがクリーンアップされる前に、エラーが発生した場合には、ITestEventListenerに反応させます。私はクラスを作成した私のテストアセンブリに

namespace My.Whatever.Tests.Web.Util 
{ 
    [Extension(EngineVersion = "3.4")] 
    public class NunitEventListener : ITestEventListener 
    { 
     public void OnTestEvent(string report) 
     { 
      Debug.WriteLine(report); 
     } 
    } 
} 

その後、私は

  • VS(NUnitの3テストアダプタ)
  • を通じてテストを実行しようとした私はを試してみました何

    nUnitコンソール

この拡張機能はロードされていないようです。

質問:私は間違っていますか?情報の

出典:https://github.com/nunit/docs/wiki/Event-Listenershttps://github.com/nunit/docs/wiki/Writing-Engine-Extensions

答えて

1

拡張があなたが言及して2つの基準の第二からリンクされているhttps://github.com/nunit/docs/wiki/Engine-Extensibility#locating-addinsで発見されたどのように配置されるかについての情報。

テストアセンブリで拡張機能が検索されません。私たちは、拡張機能をテストする簡単な方法としてNUnit Addins for V2を提供しましたが、エンジン拡張のためにそれを行うのはもう少し複雑です。私たちがその作業を行うことができればよいのですが、新しいテストアセンブリが実行されるときにすべての拡張機能をロードしたりアンロードすることができます。これは私たちの拡張サービスの主要な内部変更です。

エンジンアセンブリが格納されているディレクトリに、.addinsの1つ以上のファイルがあります。 1つではなく、どれくらいのものが含まれているかは、ランナーとエンジンをどのようにインストールしたかによって異なります。そのファイルには、エンジンの特定のコピーに対してインストールされている拡張機能を示すエントリがあります。詳細については、上記のリファレンスページを参照してください。

2例では、拡張機能の位置が原因​​.addinsファイル内のワイルドカードエントリが存在するために、多かれ少なかれ自動です:

  1. あなたはNuGetを使用してコンソールランナーをインストールする場合は任意の拡張子がインストールナゲットパッケージが見つかると

  2. Chocolateyを使用してコンソールランナーをインストールした場合、chocolateyによってインストールされた拡張機能が見つかります。

それ以外の場合は、.addinsファイルを手動で編集する必要があります。

アダプターの特定のケースでは、.addinsファイルがないため、拡張子が一切ロードされません。理論的には、少なくともエンジンがアクセス権のあるディレクトリにインストールされている場合は、手動でそのようなファイルを作成し、拡張機能をロードさせることができます。これは、あなたがナゲットパッケージを使用している場合に当てはまります。私はあなたが最初に試してみることをお勧めしますあなたの拡張子をコンソールランナーの下で認識してこれを試す前に、それは追加の合併症を伴うでしょう。

ところで、すべてのサードパーティのランナーがエンジンを使用しているわけではありません。エンジンをまったく使用していない場合は、もちろん、拡張機能を提供することはできません。

アップデート:TearDownOneTimeTearDownは、SetUp or OneTimeSetUp`が成功したときにのみ実行されることに気付きました。それは真実ではありません。両方の種類のティアダウンは、成功するかどうかにかかわらず、対応する設定がの実行の場合にのみ実行されます。もちろん、あなたのティアダウンは、対応するセットアップが完了していないかもしれないという事実を考慮して書かれなければならず、それは扱いにくいことがあります。

+0

私は答えとしてこれを受け入れますが、私の場合は「テストに失敗しました」というイベントを購読する方法は他にもありますか?さもなければ、私が見ることができる最も簡単なことは、AOPを使うか、動的にILを出して、実行時のコードにパッチを当てることです。 –

+0

私の答えの更新を見てください。あなたがしたいのは、テストが失敗したことに注意するだけであれば、ティアダウンの1つでテストを行うことができるはずです。具体的には、最後のティアダウンで実行します。これは最初のセットアップ実行に相当します。私はそのティアダウンが実行されない状況は考えられません。 – Charlie

+0

こんにちはMr Poole、私はそれを数回検証しました。私は次のシナリオに当たっています:1)私のテストはOneTimeSetUpとSetUpを持っています。 2)SetUpは、空になるようにオーバーライドされた基本クラスの仮想メソッドです。 3)OneTimeSetupはオブジェクトを作成します。 4)チームシティログに表示されるもの:SetUp ErrorはOneTimeSetupを指し、オブジェクトの初期化内でinvalidOperationExceptionが発生し、OneTimeTearDownは実行されません。私のoneTimeTearDownはこのケースを予期しており、呼び出されると(ログを生成する)実行されます。しかし、そうではありませんでした。 –

関連する問題