Nunit: 新しいクローン後のnunit.framework.testsでのユニットテストの失敗

レポートありがとうございます！ TestCaseSourceCanAccessWorkDirectoryとCommandLineTestsがテストエクスプローラーで機能しないことを確認しました。 ランナーや並列処理から独立させる方法を考え出す必要があります。 @ nunit / framework-team何かアイデアはありますか？

2番目のエラーについては、それは嗅覚テストです。 それを5に上げるのは理にかなっています。

以前は、NUnitテストにテストエクスプローラーを使用しないように指示しました。 他のチームメンバーは、テストエクスプローラーが、多くの人にとって、テストを実行するためのデフォルトの方法になっていると言って反対しています。

テストフレームワークをテストするときに特定のランナーが役に立たないという前例は確かに十分にあります。 テスト中のフレームワークのテストは非常に特殊な状況であり、ほとんどのユーザーが遭遇する状況ではありません。 OTOH、チームが望むなら、アダプターを介してテストエクスプローラーで正常に実行できるようにすることを目標にするかもしれません。

何をするにしても、テストエクスプローラーでNUnitテストを実行しても現在は機能しないことを人々に伝えるドキュメントを作成する必要があると思います。 その文脈で、それを機能させることが目標であるか、それが優先事項ではないかのどちらかが決定されていることを彼らに伝えることができます。

アダプターの最初の作成者であり、フレームワークへの長年の貢献者として、私は常にNUnitの開発におけるテストエクスプローラーの使用を非難してきました。 それはまだこの問題に関する私の見解です。 ちなみに、今はコンソールを使用してCIのフレームワークをテストするのも好きではありません!!!

決定がどうであれ、アダプターが原因であるかどうかにかかわらず、問題が発生した場合は、実際のNUnitランナー（NUnitLiteまたはコンソールランナー）にユーザーを送り返す必要があると思います。 アダプターは、NUnitプロジェクトの下にある場合でも、基本的にサードパーティのランナーと同等です。

外から見たFWIW：文書化されている限り、どちらの方法でカットするかは私には関係ありません。

箱から出して、開発者として、私が内部で使用しているのと同じ方法を使用している新しいプロジェクトに遭遇したときに、通常行うことを実行しようとします。

1. コードのクローンを作成する
2. README.md/BUILD.md/HACKING.mdをお読みください
3. ビルドを試みます（変更なし）
4. （統合されたランナーを介して）ユニットテストを実行します。
5. すべてがうまくいったら、もので遊んでください。

以前はこれはReSharperのdotCoverでしたが、「ほとんど機能する」フリー/オープンソースソフトウェアの代替手段がある場合、ライセンスコストは小さなショップ/個々の開発者にとっては狂っているので、私たちはそれをやめようとしています。

統合開発環境の概念には（私の意見では）多くのことがあります。ワークフローから飛び出す必要がないことは非常に便利です。それが私たちがそれを行う理由です。

ただし、私の頭の中で問題のないコンソールランナー（または他のランナー）を使用することが予想される場合は、それを文書化してください。

NUnitで開発し、フレームワークで作業している場合、特別な方法（R＃、独自のアダプター）で処理を行うランナーを混在させると、問題が混乱する可能性があると思います。 ランナーでテストする前に、フレームワークが単独で正しく機能することを知りたいです。 そのため、私自身の仕事では、CIを開発してローカルで実行するときに、nunitliteを使用してテストします。 テストエクスプローラーでNUnitを開発したい場合は、CIをローカルで実行し、問題があるように見える場合はnunitliteまたはnunit3-consoleにフォールバックする必要があります。

特定のリリースからnunitテストを実行しているだけの人にとっては、もっと自由度があると思います。

CIを正規化する必要があります。おそらく、すべてのフレームワークテストにNUnitLiteを使用し、次にコンソール、VSTestアダプター、エンドツーエンドテストにUWPランナーを使用します。

CIが安定していると仮定すると、Test Explorer、ReSharper、NCrunch、およびCIスクリプトの間に微妙な違いがあれば問題ないようです。 これらのIDE内ツールを無視する必要があると言うことは、私が貢献への障壁と見なしていることであり、それは私のワークフローでもないため、誤りです。 私の理想的なワークフロー：

1. 既存のテストを見つけるか、新しいテストを作成します
2. そのテストフィクスチャを固定して、入力中にテストをすばやく再実行できるようにします（さらに良いことに、継続的テストを開始します）
3. 変更を実装する
4. Gitコミットを作成する前に、 .\build.ps1 -t testを実行して、合格と不合格が期待どおりであることを確認します
5. 驚きがある場合は、私が知らなかった影響を受けたテストを見つけて固定し、ステップ3に進みます。

テストがランナーに依存しないというまれなシナリオでは、テストをランナーに依存しないようにするのが難しいかどうかはわかりません。 これは、ReSharperおよびNCrunchシャドウコピーに対して復元力を持たせたILMerge用に作成した統合テストよりも悪いことはありません。

@aolszowka私は、私たちが何をするにしても、投稿ドキュメントを使いやすく最新の状態に保つことで、投稿者の時間を尊重する必要があるというあなたの意見に100％同意します。

@ jnm2私はあなたの「標準的な」アプローチが好きです。 テストエクスプローラーですべてをスムーズに動作させるのは簡単かどうかは疑問ですが、試してみる価値はあります。

nunitで作業している人にとって、より低いレベルのテストにいつ切り替えるかを知ることは、依然として有用であり、不可欠です。

このアイデアを前進させるために私たちができる最大のことは、IMOは、別個のシステムとおそらく統合テストを確立することです。

これが根本的な原因である可能性があります。 FrameworkControllerからXMLを取得するためのテストを作成しているときに、 TestContext.WorkDirectoryがC:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE変更されていることに気付きました。

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/Api/DefaultTestAssemblyBuilder.cs#L137

コールスタック：

>   nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(System.Reflection.Assembly assembly, string suiteName, System.Collections.Generic.IDictionary<string, object> options) Line 137    C#
    nunit.framework.dll!NUnit.Framework.Api.DefaultTestAssemblyBuilder.Build(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> options) Line 114    C#
    nunit.framework.dll!NUnit.Framework.Api.NUnitTestAssemblyRunner.Load(string assemblyNameOrPath, System.Collections.Generic.IDictionary<string, object> settings) Line 154   C#
    nunit.framework.dll!NUnit.Framework.Api.FrameworkController.LoadTests() Line 204    C#

これは、 TestContext.WorkDirectoryが静的な可変状態であるためです。

https://github.com/nunit/nunit/blob/81fcc7c047c09fcb5a86989d0829716ca7d08e1e/src/NUnitFramework/framework/TestContext.cs#L96 -L101

つまり、同時テストを含むすべてのテスト（！）で共有されます。 WorkDirectoryに依存するテストを正しく行うには、 [NonParallelizable]マークを付ける必要があります。

私はずっと前にこの問題に気づきました。 どこかに問題があります。

NonParallelizableは十分ではありません。 いずれかのテストがWorkDirectoryを変更する場合（多くのNUnitテストが行​​うように）、それに依存する他のテストが失敗する可能性は十分にあります。

これはすべて、テストが実行される順序に依存します。これは、NUnitでは定義されていません。

作業ディレクトリは一度設定し、実行中は変更しないでください。 それ以外はバグです。

実行コンテキストごとに独立した作業ディレクトリを許可できない理由はありますか？

@CharliePooleどうすればそれを実現できますか？ フレームワークは、コントローラー実行内で実行されるコントローラーであるFrameworkControllerをテストするため、私たちは特別な立場にあります。

テストは別として、 WorkDirectoryの意味は、「実行用のすべての出力ファイルを受信するためにユーザーが設定したディレクトリ」です。 したがって、テストで変更できないようにする必要があります。

私たち自身のテストでは、それを設定できる必要がありますが、正しく実行すれば、その設定が他のテストに影響を与えることはありません。 私たちはおそらくそれを正しく行っていません。 😜

ピンチでは、変更できないようにして、テストを停止することができます。 <ducks>

それは実際にはクールなアイデアです-静的フィールドが設定されているかどうかを追跡し、その後は設定をスキップしますか？ そうすれば、それは変更できず、 DefaultTestAssemblyBuilderがそれを設定するかどうかをチェックするテストが表示されないので、問題ないはずです。

それを変更するNUnitテストがあり、変更できないようにすると失敗する可能性があります。

@oznetmaster検索しましたが、偶然を除いて、それを変更するNUnitテストが見つかりませんでした。 何か便利なものはありますか？

アーカイブを検索する必要があります。

すでに説明したことを実行して、CFビルドの問題を修正しました。 値の設定は1回のみです。 nullであることを確認し、nullの場合は、設定できるようにします。

                if (options.ContainsKey (FrameworkPackageSettings.WorkDirectory))
                    TestContext.DefaultWorkDirectory = options[FrameworkPackageSettings.WorkDirectory] as string;
                else
                    if (TestContext.DefaultWorkDirectory == null)
                        TestContext.DefaultWorkDirectory = Directory.GetCurrentDirectory ();

問題となったテストは、FrameworkPackageSettings.WorkDirectoryを含まないオプションを指定してDefaultTestAssemblyBuilder.Buildを呼び出し、TestContext.DefaultWorkDirectoryがCurrentDirectoryによって上書きされるテストでした。 これは、WorkDirectoryが最上位の実行で設定されている場合、テストによって上書きされ、復元されないことを意味しました。

同じアプローチを取るのが良いと思いますか？

私のために働きます。 私のCFビルドはNUnitテストの100％に合格しています。

@OmicronPersei数日以内にいる場合は、 @ oznetmasterの修正を

はい！ 今晩やってみます

nunit3-vs-adapter＃528が他の問題を引き起こしているため、このバグを実際に再現することはできません。 アイデア？

@OmicronPerseiああ。 わからない。 WorkDirectoryが正しく設定された.runsettingsを使用することは、適切な回避策でしょうか？

さて、私はそれを試しました。 TestCaseSourceCanAccessWorkDirectory成功しますが、 StackTracesAreFilteredは、OP内の同じメッセージ/スタックトレースで失敗します。

StackTracesAreFilteredを5に上げる必要があると思います。これは匂いテストであり、新しいフレームが追加されたかどうかを確認して、制御不能になっていないことを確認できます。

TestCaseSourceCanAccessWorkDirectoryはどうですか、それともこのPRの範囲内ですか？

ForTestCaseCanAccessWorkDirectory、 @ oznetmasterの修正はそれを解決しますか？ そうでない場合は、さらに調査する必要があります。

自分のマシンで問題を再現できません。問題のテストに合格しました。

心配はいりません、他の誰かがその部分を行うことができます。 私もPRを小さくするのが好きです。

家の掃除をしようとしているだけです。 この問題がまだ開いている必要がある理由はありますか、それとも何らかの解決策で閉じることができますか？ （WONTFIXであっても）。

いいえ、指摘していただきありがとうございます。 閉鎖。