Nunit: テストケースごとのインスタンス機能

現在、（1）コンストラクターまたは1回限りのセットアップで状態を設定し、（2）どのテストでも状態を変更しないという条件で、並列テスト間で状態を__can__共有できます。 テストまたはセットアップで状態が定数に設定されている場合は、他の値に設定しない限り、うまくいく場合もあります。 後者は、それを行うNUnitテストがいくつかあると思いますが、厄介です。

私の考えでは、デフォルトをすぐに変更することはできません。 可変状態であることは、現時点ではバグを保証するものではありません。 実際に変更した場合のバグであり、コード分析を行わない限り、それはわかりません。

テスト、セットアップ、またはティアダウン内でインスタンスの状態を変更しない場合、破損することはありません。 そうした場合、テストがそれ自体と並行して実行できる限り、あなたはすでに壊れています。 私が考えることができるようにあなたが壊れていない方法はありません。 結果として生じるユーザーの複雑さが「賢明なデフォルト」の結果に値すると考える場合、これは自動オプションの正当化です。

あなたにはポイントがありますが、これは潜在的な拡張であり、現時点で決定する必要はありません。 今すぐすべての決定を下そうとするのではなく、これを繰り返し実行しましょう。

私は@CharliePooleを使用してい

すべてのスレッドで共有されるインスタンスではなく、スレッドごとにインスタンスをトリガーするフィクスチャレベルの属性かもしれません。

@BlythMeister心配しないでください！ 既存のコードが壊れ始める原因となる変更は考慮していません。

これは面白い。 インスタンスごとのテストケースは、インスタンスごとのスレッドよりも簡単に頭を悩ませることができると思います。 テストがスレッドに割り当てられる方法は信頼できないため、テストケースごとのインスタンスよりもメリットがあるとは考えられません。

ええ、私はスレッドという用語を並列実行を意味するために使用しています....これは実際には不正確です。
謝罪いたします。

XPの用語では（そして、それが常に私の視点であることを誰もが知っていることを願っています）、3つのストーリーがあります。

1. ユーザーは、アセンブリ内のすべてのフィクスチャに対して、テストケースごとのインスタンスの動作をグローバルに指定できます。

2. ユーザーは、フィクスチャでテストケースごとのインスタンスの動作を指定できます。

3. ユーザーは、並行して実行される可能性のあるテストを含むフィクスチャに対して、テストケースごとのインスタンスの動作を指定できます。

この号で（1）が完全に実装されることを望んでいます。 今のところ、（2）を頭から外すか、少なくともコードを書く部分から外す必要があると思います。 （3）は可能性があると思いますが、他の問題ですでに遭遇したいくつかの落とし穴があります。 （フィクスチャは、テストケースを並行して実行するかどうかを知りません！）（1）と（2）が完了してマージされた後の1つのJustInTimeについて話しましょう。 FWIW、私たちはいくつかの動きを先に考えようとすることによって結び目で縛られる傾向があると思います。 （2）と（3）については、ブロックしないように説明しましたが、これは簡単に回避できるようです。

その時、私たちは皆同意していると思います。 ただし、この前にNUnitの優先順位がいくつかあるので、他の人がコメントしたり、場合によっては取り上げたりできるようにしておきます。

コマンドライン設定ではなく属性を使用してこれを行うことの利点は、どのランナーでも機能することです。

@CharliePooleが属性であるべきだということに同意します。 テストは、テストごとのインスタンスまたはフィクスチャごとのインスタンスを念頭に置いて設計する必要があるため、常にそのように実行する必要があります。 また、オプション1のみを実行することを好みます。そのスタイルのテストが必要な場合は、テストスイート全体でオプトインする必要があると思います。 より低いレベルでオプトインできるようにすると、複雑さが増し、ROIが良くないと思います。

この機能を実装する差し迫った計画があるかどうかだけ知りたいですか？

@rprouseこれはまだ設計が必要であるとマークされていますが、議論はすでにすべてをカバーしているように見えます。

@CharliePooleは、これが設計から移行する可能性があることに同意しました。 @pfluegs設計以外の作業は開始していないため、まだ計画はありません。

誰もがそれにそれほど注意を払っているのかどうかはわかりませんが、議論やデザインラベルがないということは、誰かが志願できることを意味します。 😄

私はちょうどこの問題にひどく噛まれました-修正のために+1。

より多くのオプションが必要な場合は、次のようにします。

`` `c＃
[アセンブリ：FixtureCreation（FixtureCreationOptions.PerTestCase）]

And:
```diff
namespace NUnit.Framework
{
+   public enum FixtureCreationOptions
+   {
+       Singleton, // = default
+       PerTestCase
+   }
}

少なくとも新しいフレームワークのコンテキストでは、これに関する私自身の考え方は少し変わりました。

私は今、2つのクラスレベルの属性が必要だと思います。1つは動作ごとに1つです。 TestFixtureをテストごとのインスタンスで動作させ、SharedFixtureをNUnitのように動作させます。 明らかに、これはNUnitのコンテキストにおける重大な変更ですが、一般的なアプローチは検討する価値があるかもしれません。

@CharliePoole [TestFixture(FixtureOptions.PerTestCase)]は良い構文のように見えますが、すべてのテストプロジェクトでオプトインできるように、アセンブリレベルの属性も必要です。 アセンブリレベルの属性をどのように見せたいですか？

そうです、それが私が新しいフレームワークで何をするかを予約WRTに表現した理由です。 ただし、NUnitの場合、 TestFixtureのセマンティクスを変更したくないので、インスタンスごとの動作に本当に適した名前を考えることはできません。 名前が2つある場合、すべてのフィクスチャで目的の動作を実現するために必要なのは、ソースファイルのグローバル編集を行うことだけです。

アセンブリレベルでのグローバル設定は、AssemblyInfoファイルに何が設定されているかを認識していない開発者を混乱させるため、嫌いです。 現在、いくつか許可しているので、さらに追加しても大きな害はないと思います。 アセンブリ内のすべてのフィクスチャにオプション（デフォルト？）を設定していることを通知する必要があることを除いて、アセンブリレベル属性の名前については考えていません。

おっしゃる理由から、アセンブリレベルのデフォルトもある程度嫌いです。 現在属性のないフィクスチャクラスのそれぞれに新しい属性を追加するのと比較して、アセンブリレベルの属性は私が好むルートです。

@ nunit / framework-teamどう思いますか？ 機能の最初の導入について：

• アセンブリレベルの設定に「はい/いいえ」？
• フィクスチャレベルの設定にはい/いいえ？
• メソッドレベルの設定にyes / no？
• テストケースレベルの設定に「はい/いいえ」？

属性のないフィクスチャクラスの良い点。

はい、はい、いいえ、いいえ

私はチャーリーに同意します-「フィクスチャレベル」は「クラスレベル」を意味するという明確化で。 （たとえば、テストケースソースメソッドとは対照的です。😊）

それは役に立ちます！ したがって、 [TestFixture(FixtureCreationOptions.PerTestCase)]の問題は、同じクラスで複数のTestFixture属性が許可され、それらが互いに矛盾する可能性があることです。 アセンブリとクラスに適用可能な新しい名前付き属性を使用する方が、より簡単でしょうか。

`` `c＃
[アセンブリ：ShareFixtureInstances（false）]

[ShareFixtureInstances（false）]
パブリッククラスSomeFixture
{{
//..。
}

Framework API:

```diff
namespace NUnit.Framework
{
+   [AttributeUsage(AttributeTargets.Assembly | AttributeTargets.Class)]
+   public sealed class ShareFixtureInstancesAttribute : PropertyAttribute
+   {
+       public bool ShareFixtureInstances { get; }

+       public ShareFixtureInstancesAttribute(bool shareFixtureInstances);
+   }
}

いいですね。 これの継承動作は何ですか？独自のテストを使用して基本クラスに属性があり、そのクラスからも継承する場合はどうなりますか？ 😊

おそらく、それは「クラス」属性であるため、問題のテストが実行されている実際のクラスにある必要がありますか？

また、私は名前に完全に熱心ではありません-フィクスチャは必ずしもnunit用語のクラスではないので、私は思いません（たとえば、「suite」と「fixture」がより強いセマンティクスを持っていない限り、テストケースソースのすべてのテスト- Nunitの用語では、私が思っているよりも意味があります！）

InstancePerTestに沿ったものはどうですか...しかし、より適切な名前が付けられています...

アセンブリレベルとクラスレベルについては合意しましたが、それ以上はありません。 また、 @ ChrisMaddockの提案ClassInstancePerTest(bool)沿ったものが好きです。 また、クラスレベルの属性がアセンブリレベルをオーバーライドし、継承されることを期待しています。 通常、並列処理と組み合わせたクラスのメンバーに基づいてテストごとにインスタンスが必要になるため、継承は重要だと思います。 したがって、それを派生クラスに自動的に適用する必要があります。

私はかつて、テストフィクスチャタイプが構築可能である場合、NUnitがテストごとにインスタンスを作成しないことに本当に驚いてユニットテスト：足場を設定し、テストを実行すると、足場がなくなります。 テスト間での不注意による状態の移行はありません。

それを学んだ。 @ jnm2のように、テストを手動でインスタンス化します。 ただし、ファイルの作成や削除などのテストを行うと、ケースランナーは本当に面倒になります。IDisposableである必要があります。 もう魔法の[TearDown]はありません。 :(テストエラーとスキャフォールディングエラーを区別する一貫した方法もありません。これは非常に苦痛なユースケースです。

私がデザインに割り込むかもしれないなら、私ははい、はい、いいえ、いいえで一緒です。

PerTestInstance 、 InstancePerTestなどの名前PerTestInstance 、 ShareFixtureInstancesよりもはるかに優れています。 F＃コードをテストしているとき、型インスタンスがクラスであるとは思わないので、属性の名前にあるClassという単語は少し嫌いです。 しかし、私がそれと一緒に暮らせることは確かです！ :)

ああ、この機能が待ちきれません！

@ kkm000 「クラス」の使用について同意します。 NUnitは通常、実装とは異なる名前を使用しています。 それでも、人々は思い込みをしますが、そのようなことを避けるために一貫している方が良いです。

私が話していることの例：Test、TestFixture、SetUpFixture、Worker（スレッドではない）など。原則として、クラス__could__は、フィクスチャではなく単一のテストを表します。すべきですが、__私たちは__できました。

@ kkm000

コメントありがとうございます！ あなたはまったく介入していません。 私たちは、可能な限り言語にとらわれないという設計目標を持っています。
C＃に焦点を当てる以外に、 classという単語についてもう1つ、クラスではないフィクスチャをサポートする場合はどうなるでしょうか。

[InstancePerTestCase]は問題を回避しますが、直感的な明瞭さが失われる可能性があります。

今日、フィクスチャとクラスはあまり発散していませんが、発散した場合、この属性はクラスではなくフィクスチャに関係していると確信しています。

スイートは一般的な組織の概念ですが、フィクスチャはセットアップ/ティアダウンロジックとテスト状態を保持し、テストメソッドに渡されます（現在はインスタンスメソッドのthis引数として）。 備品は、組織階層の一部である必要はありません。 クラスの概念から分岐し、テストスイートの概念から分岐するフィクスチャを想像してみましょう。

`` `c＃
public static class SomeTestSuite //フィクスチャではありません：セットアップ/ティアダウンロジックもテスト状態もありません
{{
[テスト] //単一のテストであり、パラメーター化されたスイートではありません。
//フィクスチャは、暗黙のthisパラメータではなくパラメータを介して注入されます
public static void SomeTest（SomeFixtureフィクスチャ）
{{
フィクスチャ.SomeService.SomeProperty = true;
フィクスチャ.SomeAction（）;
フィクスチャ.AssertSomething（）;
}
}

[テストフィクスチャ]
public struct SomeFixture：IDisposable
{{
public SomeService SomeService {get; } // 州

public SomeFixture() // This was almost legal syntax in C# 6, but I'm making a point 😁
{
    // Setup
}

public void Dispose()
{
    // Teardown
}

public void SomeAction()
{
    // Helper method
}

public void AssertSomething()
{
    // Helper method
}

}
`` `

上記の例では、 [FixtureInstancePerTestCase]または[SharedFixtureInstances(false)]はクラスに焦点を当てておらず、階層（スイート）にも焦点を当てていません。フィクスチャに焦点を当てており、フィクスチャは再利用可能なセットアップ/ティアダウンロジックおよび状態です。 具体的には、テストケースごとに新しいSomeFixtureが作成されるかどうか、または同じものが各テストに渡されるかどうかに焦点を当てています。

この属性は、異なるITestがITest.Fixtureインスタンスを共有するかどうかを制御し、制御されるのは[TestFixture] （名前にFixtureれる別の属性）で装飾するものであるため、フィクスチャという単語を使用するための_consistent_オプション。

（私は議論するのに重要と思われる点を持ってきていますが、私はその名前がどうなるかについてはあまり投資していません。）

@ jnm2スイートとフィクスチャの概念が分離可能であることは

私の知る限り、xunit.netは、フィクスチャをテスト継承階層とは別のエンティティにする最初の（唯一の？）フレームワークでした。

パラメータ化されたテストを作成したとき、別の「フィクスチャ」としてTestCaseSourceを導入できたはずです。 私はそれをしませんでした、そして私はそれをやり直すために必要な変更が今壊れていると思います。

人々が時々（並列処理の前に）インスタンスごとの動作について尋ねる理由は、それが他のフレームワークが行うことだからだと思います。 同様の理由で、彼らは分離可能な備品を__しませんでした__。

要約すると、これが私が思うことです...

1. テストケースごとの動作にインスタンスが必要です。

2. 下位互換性があるため、デフォルトにすることはできません。

3. 分離可能なフィクスチャはクールなアイデアですが、別の問題でもあります。

4. 分離可能なフィクスチャは、インスタンスごとのフィクスチャと少なくとも同じくらい複雑に実装できます。 もちろん、この場合は下位互換性に対処する必要がないため、簡単になります。

ポイント3と4について確認するために、コードサンプルを新機能の提案としてではなく、この属性の正しい名前にたどり着くのに役立つ思考実験として意図しました。 思考実験は、私たちがフィクスチャのアイデアに本当に焦点を合わせていることを私に教えてくれます。それらはたまたま一致しているにもかかわらず、クラスやスイートではありません。

どのような形式であっても、フィクスチャはセットアップ/ティアダウン/状態の再利用可能な定義です。 それがその言葉の意味だと思います。 フィクスチャインスタンス（セットアップ/ティアダウン/状態の発生）は、新しい属性がテストケース間で共有するかどうかを決定するものです。 名前のどこかにFixtureInstancesがあると、最大の明瞭さがもたらされると思います。

これは誰にとっても正しいように思われますか？ そうでない場合、他にどのような点を考慮することができますか？

ああ！ 申し訳ありませんが、あなたは非常に良い点に当たったと思いました。通常は見落とされていましたが、私たちが逸脱しているのではないかと心配していました。 ：slightly_frowning_face：

フルネーム（入力するものは何でも）には、フィクスチャとインスタンスの両方を含める必要があると思います。 それがどのように行われるかは、属性名について話しているのか、それを構築する際に使用される列挙型について話しているのかによって異なります。 どちらに落ち着いたのかわからない。

はい、良い点です。

列挙型を実行すると、入力に時間がかかります。 これは、アセンブリを対象とした属性よりも、クラスを対象とした属性の方が重要です。 また、同じクラスで複数のTestFixtureAttributesが許可されており、一方のパラメーターが他方のパラメーターと矛盾する可能性があるため、列挙型をパラメーターとしてTestFixtureAttribute追加しないようにする必要があります。 これはテスト時のエラーで処理できますが、通常は無効な状態を表現できないようにすることをお勧めします。

いくつかのオプションを考えてみましょう。そこから微調整できます。
直感性、NUnitのスタイルとの一貫性、適切な柔軟性のバランスが取れたものを探しています。 （ほとんどの場合、これらはすでに重複しているはずです。😄）

提案A

`` `c＃
[アセンブリ：FixtureOptions（InstancePerTestCase = true）]

[FixtureOptions（InstancePerTestCase = false）]
クラスSomeFixture
{{
}

Pro: extending later if there's ever more options for fixture handling (doubtful?)
Pro: two names so there's less stuffed into a single name
Con: `[FixtureOptions]` would be legal but highly misunderstandable syntax. (Does it reset the assembly-wide setting to the default, `false`, or does it have no effect, e.g. `null`?)


### Proposal B

```c#
[assembly: FixtureOptions(FixtureCreationOptions.PerTestCase)]

[FixtureOptions(FixtureCreationOptions.Singleton)]
class SomeFixture
{
}

public enum FixtureCreationOptions
{
    Singleton, // = default
    PerTestCase,
    // Doubtful there will be other options?
    // Maybe Pool, where we reset and reuse between nonconcurrent tests?    
}

長所：無効な状態は表現できません
長所：フィクスチャ処理のオプションがさらにある場合は後で拡張します（疑わしいですか？）
短所：属性名と列挙型名の両方を入力する際の冗長性

提案C

`` `c＃
[アセンブリ：FixtureInstancePerTestCase]

[FixtureInstancePerTestCase（false）]
クラスSomeFixture
{{
}
`` `

長所：無効な状態は表現できません
プロ：誤解しにくいです（ただし、私は新しいユーザーではないため、ここに盲点があります）
短所：長い名前
多分短所：オプションと値の両方を指定できる非常に具体的な名前。 （しかし、私が好きな[NonParallelizable]あります。）

（別の提案を歓迎します！）

2つの属性を持っていることについて言うべきことがあります。1つはアセンブリ用で、もう1つはクラス自体用です。

長所：コンテキスト内で動作が異なる1つの属性ではなく、2つの単純な属性を実装する方が簡単です。 （ParallelizableAttributeから学んだ教訓）
長所：それぞれに適切な名前を付けることができるため、ユーザーが理解しやすいと思われます。 たとえば、アセンブリレベルに「デフォルト」という単語を含めることができます。
短所：覚えておくべき2つの属性。

それぞれの選択肢を使用したアプローチ：

`` `C＃
[アセンブリ：DefaultFixtureOptions（InstancePerTestCase = true）]

[FixtureOptions（InstancePerTestCase = false）]
クラスSomeFixture
{{
}

[アセンブリ：DefaultFixtureOptions（FixtureCreationOptions.PerTestCase）]

[FixtureOptions（FixtureCreationOptions.Singleton）]
クラスSomeFixture
{{
}

[アセンブリ：DefaultFixtureInstancePerTestCase]

[FixtureInstancePerTestCase（false）]
クラスSomeFixture
{{
}
`` `

他のコメント：

• 私はCよりもAとBの方が好きです
• 共有フィクスチャの動作を「シングルトン」と呼ぶべきではありません。 ：smile：継承すると、ベースフィクスチャの複数のインスタンスを取得します。
• アセンブリレベルとフィクスチャレベルで別々の属性を使用する場合、実際にはフィクスチャレベルの名前からフィクスチャを削除できます。
• SetUpFixturesがこれにどのように適合するかはまったく指定していません。 それらには問題があり、属性が使用されている場合は実行時エラーが必要になる場合があります。 実際、完全に別個の属性の利点の1つは、これに対処する必要がないことです。 （これは、TestFixture、BTWのプロパティの利点でもあります）
• テストケースごとのインスタンスは静的クラスに適用されないことを人々に警告する必要があります。 それは私たち全員にとって明らかですが、すぐにそれを理解しない人々がいます。

ところで、アセンブリレベルとフィクスチャレベルにDefaultTestCaseTimeOutを使用し、メソッドのみにタイムアウトを設定したいと思っていました。

この可能性を提起してくれてありがとう。

今私を悩ませているのは、私たちがこの方向に進んでいないとしても、これは理論的には理にかなっている可能性があるということです。

c# [DefaultFixtureOptions(InstancePerTestCase = true)] class SomeFixture { [FixtureOptions(InstancePerTestCase = false)] public void SomeTest() { } }

これが実際に実行されるレベルは、フィクスチャレベル自体ではなく、テストケースレベルであるためです。
例として、派生フィクスチャは基本フィクスチャの設定をオーバーライドする場合がありますが、実際に行われているのは、派生クラスによって生成された各テストケースの設定に影響を与えることだけです。

または：

`` `c＃
[アセンブリ：DefaultFixtureOptions（InstancePerTestCase = true）]

//これもデフォルトと見なされるべきではないのはなぜですか？
[DefaultFixtureOptions（InstancePerTestCase = true）]
パブリック抽象クラスBaseFixture
{{
}

パブリックシールクラスSomeFixture：BaseFixture
{{
}
`` `

Defaultをいつ、いつ使用しないかについての論理的根拠をどのように考え出すのですか？

この属性を各テストケースに実装すると、非常に複雑になりますが、メリットはわずかです。

「通常の」テストフィクスチャの場合、テストフィクスチャに関連付けられたコマンドチェーンの一部としてインスタンスをインスタンス化し続けます。 たとえば、テストごとのフィクスチャの場合、そこでインスタンス化することはありませんが、テストチェーンの一部として新しいコマンドを実装する必要があります。これは、フィクスチャチェーンで現在行われていることとほぼ同じことを行います。

フィクスチャに両方のタイプのテストが含まれている可能性がある場合は、モデルごとに1回ずつ、2回実行する必要があります。

ユーザーはテストを別々のフィクスチャに分割することで同じことを簡単に達成できるため、メリットは小さいように思われます。 結局のところ、フィクスチャはNUnitアーティファクトであり、同じフィクスチャの動作を必要とするテストを同じフィクスチャに配置するようにユーザーに要求することは合理的です。

「デフォルト」をいつ使用するかについては、どのTestFixxtureでも使用せず、アセンブリレベルでのみ使用するように思われます。 属性は継承によって派生クラスで実際に見つかるため、基本クラスも例外ではありません。 したがって、ベースで特定の動作を設定することはデフォルトではありません。 むしろ、それはそのクラスとそれから派生したものの設定です。 現在継承されている属性のすべての場合と同様に、矛盾する仕様はエラーを引き起こすか無視する必要があります。 つまり、属性Aを基本クラスに配置し、Bを派生クラスに配置することは、AとBを基本クラスに直接配置することと区別されません。 ユーザーが他のことをするのは意外なので、そのように設計しました。

WRTセットアップフィクスチャ、ところで、そこでいずれかのインスタンス化オプションを指定すると、ランタイムエラーが生成されるはずです。 SetUpFixturesはTestFixturesではありません。

つまり、属性Aを基本クラスに配置し、Bを派生クラスに配置することは、AとBを基本クラスに直接配置することと区別されません。 ユーザーが他のことをするのは意外なので、そのように設計しました。

ああ、私は[Apartment]または[Parallelizable]が基本クラスまたは基本メソッドの設定を置き換えることを期待していました！

これはすべて私には理にかなっています。

FixtureCreationOptionsなどの列挙型が必要であることを除外できますか？ PerTestCase 、 PerFixture 、架空のReusedPerTestCase ？

私は次の単純さに傾いています：

`` `c＃
[アセンブリ：DefaultFixtureOptions（InstancePerTestCase = true）]

[FixtureOptions（InstancePerTestCase = false）]
クラスSomeFixture
{{
}

Hypothetical other creation options would then be added this way:
```c#
[FixtureOptions(InstancePerTestCase = false, ReuseInstances = true)]

@ nunit / framework-teamあなたの好みは何ですか？

それにかんする

[assembly: DefaultFixtureOptions(InstancePerTestCase = true)]

たぶん私だけかもしれませんが、一般的に私は、マークされたオブジェクトが特定の特性を持っていることを示すものとして属性を理解しています。 属性への引数は、もしあれば、その特性を洗練しています。 たとえば、Serializableを考えてみましょう。オブジェクトはシリアライズ可能ですが、装飾されていない場合はそうではありません。 InternalsVisibleTo--特定の何かに見える内部。引数はこれを洗練します。そうでない場合、内部は何にも見えません。一部の属性はパターンに従っていませんが、これらは通常低レベルです（例：CompilationRepresentation、MethodImpl）。 これらには通常、必須のコンストラクター引数が付属しています。

今考えてみましょう
c# [assembly: DefaultFixtureOptions]
InstancePerTestCaseへの割り当てはオプションであるため、これは整形式のC＃です。 それは意味的に何を表現していますか？

私には、 [assembly: DefaultFixtureInstancePerTestCase]方が自然に思えます（セスキペダリアン名を除いて、それは単なる意見であり、美的に保存することは正当化されません）。 1つの属性、1つの特性。 おそらく、これはパラメータやオプションで設定可能なプロパティを必要としません。

また、ユーザーとして、名前が異なる2つの属性があり、1つはアセンブリレベル（ DefaultSomething ）にのみ適用可能で、もう1つはタイプレベル（ Somethingのみ）にのみ適用可能であることに驚いています。 。 当然、 @ CharliePooleがParallelizable属性に関して言及した「学習したレッスン」が何であったかはわかりませんが、島のこちら側からは、（このユーザーの表面的な考え方で）どこで行うかを学習するための属性のペアは当惑しているようです。

@ kkm000単一の特性を表す属性についてのあなたのコメントに同意します。

異なるレベルでの「同じ」特性の2つの異なる属性をWRTします。それらが実際に同じであると思った場合、私は同意します。 しかし、私は彼らがそうではないと思います。 例としてタイムアウトを使用します。

テストメソッドにタイムアウトが設定されている場合は、「実行に指定されたミリ秒数を超えると、このテストメソッドはタイムアウトになります」という意味です。 ただし、タイムアウトがフィクスチャまたはアセンブリに配置されると、意味が異なります。「このアイテムに含まれるすべてのテストケースのデフォルトのタイムアウトは、指定されたミリ秒数です。」 もちろん、そのデフォルトは、より低いレベルでオーバーライドされる可能性があります。 ちなみに、2つの別々の実装がある2つのかなり異なる意味。 1つ目は、タイムアウトが表示されるテストにタイムアウトを適用します。 2つ目は、デフォルトをテストコンテキストに格納し、含まれているテストケースが検出されたときにデフォルトとして使用されます。 ParallelizableAttributeも同様に機能します。

この特定のケースでは、フィクスチャに配置され、属性は「テストケースごとに1回このフィクスチャをインスタンス化する」ことを意味します。 アセンブリレベルでは、「特に指定がない限り、このアセンブリのテストフィクスチャをフィクスチャごとに1回インスタンス化する」ことを意味します。

この特定のケースでは、フィクスチャに配置され、属性は「テストケースごとに1回このフィクスチャをインスタンス化する」ことを意味します。 アセンブリレベルでは、「特に指定がない限り、このアセンブリのテストフィクスチャをフィクスチャごとに1回インスタンス化する」ことを意味します。

最後の文で間違った話をしたと仮定すると、_ "特に指定がない限り、このアセンブリのテストフィクスチャを〜フィクスチャ〜

私がユーザーとして、セマンティクスはまったく異なっていないように見えると仮定すると、「属性では、「内部スコープが異なってマークされていない限り、確かにそのような内部スコープです。」それがフィクスチャであろうとアセンブリであろうと。 私の意見ですが、2つの属性は少し紛らわしいように見えます。 多分それは私の考え方です、私は本当に知りません。

2つの別々の実装

ユニコーンとレインボーのゲダンケンワールドでは、実装はユーザー側に影響を与えません。 しかし、私たち（NUnitデザイナーとそのユーザーの1人）はすべてエンジニアであり、エンジニアリングは妥協がすべてです。 異なるスコープに1つの属性を使用することが、実際に内部の不器用さとメンテナンスの負担につながる場合、私はまったくグリッチしません。 :)

結局、これは小さな問題であり、同じ属性を強く感じず、どちらの方法でも属性を配置して生きることができます。

@ kkm000はい、「テストケースごとに1回」を意図していました。

ネストされた一連のスコープと考えると、すべてが完全に理にかなっていることに同意します。 ただし、経験によれば、ユーザーは（a）常にそのように考えているとは限らないか、（b）スコープの定義が正しく理解されていません。

最後の例として、ネストされたクラスと基本クラスについて考えてみましょう。 どちらもNUnitによってテスト目的でネストされた「スコープ」として扱われませんが、ユーザーにはそのように見える場合があります。

フィクスチャのタイムアウトは、フィクスチャ全体にタイムアウトが適用されることを簡単に意味する可能性があるため、タイムアウト/デフォルトタイムアウトで説明した問題はもう少し深刻ですが、もちろんそうではありません。 さらに言えば、アセンブリのタイムアウトはアセンブリ全体に適用される場合がありますが、適用されません。

この場合、名前に「テストケースごと」を使用しているため、どちらの方向にも簡単に移動できるため、あいまいさが少なくなっているようです。 とにかく取り組んでいません。 ：笑顔：

考えてみると、TimeoutがTestCaseTimeoutと呼ばれていたとしたら、もっと良かったでしょう。

私は単一の[FixtureInstancePerTestCase]満足しています。 ユーザーの精神的負担が最も少ないようです。

@ nunit / framework-team https://github.com/nunit/nunit/issues/2574#issuecomment -426347735からスキミングして、方向性を決めるのを手伝っていただけませんか？

[FixtureInstancePerTestCase]も私の最も嫌いなオプションです。 😄拡張性の欠如が唯一の欠点です。

私は[FixtureOptions]問題が好きではありません-それはあまりにも混乱していると思います。 個人的には、アセンブリとクラスの両方に単一の属性を使用したいと思います。これにより、以前はTimeoutとParalellizableの問題が発生していましたが、名前に「Fixture」が含まれていると、あいまいさが少なくなります。

私は個人的に列挙型オプションが好きだと引用しています...それをより簡潔にするために適切に名前を付ける方法を考えることができないことを除いて！

これに関する更新はありますか？

更新はこの問題に投稿されます。

誰かがこの問題を解決できますか？
現在、すべてのテストコードを次のようにラップする必要があります。
csharp [Test] public void TestExample(){ using(var tc = new MyTestContext()){ //code goes here } }
この機能を使用すると、セットアップ時にテストコンテキストを初期化し、破棄時に破棄し、スレッドセーフにすることができます。

こんにちは、私たちの会社でもこの問題に直面しています。 この機能をサポートするフレームワーク（Py.Test）から移行しているので、これはちょっとした落とし穴です。 このインスタンス化を制御するソースコードを見せていただければ、フォークして必要な変更を加えることができます。

@MChiciak
この問題がすぐに修正されない場合は、xUnitへの移行を検討しています。これは、xUnitではこれがデフォルトの動作であるためです。「xUnit.netは、実行されるすべてのテストに対してテストクラスの新しいインスタンスを作成します」 https：// xunit .github.io / docs / shared-context

@ LirazShay 、 @ MChiciak私もこの問題に遭遇しましたが、 @ CharliePooleのポイントに同意します。 そこで、SetUp [ThreadStatic]初期化されるテスト固有のフィールドを作成しましたが、正常に機能します。

@dfal
素敵な回避策をありがとう！

私はこれが大好きです。 私は現在、nunitで実行されている何千ものテストを含む既存のテストスイートを持っていますが、共有状態のために簡単に並列化することはできません。 このオプションが提供されていれば、テストスイートをはるかに簡単に並列化できます。

思考実験として、TestFixtureの動作を単純に変更したと想像してください。 これは何を壊しますか？

1. 順序付けを使用し、あるテストによって行われた状態の変更に依存して他のテストに影響を与えるテスト。 これは、（おそらく）独立した単体テストの場合には非常に悪い習慣です。 私たちは常にこれを行わないように人々に警告してきました、そして私はこのように単一のインスタンスを持つことに依存したテスト（もちろんメッセージ付き）を破ってもかまいません。

2. 1回限りのセットアップで行われることによっては、個々のフィクスチャインスタンスを並行して実行できない可能性があります。 これは皮肉なことです。変更の動機は、フィクスチャを並行して実行できるようにすることだからです。 これは、すでに並列で実行できないため、この機能を必要とする人々にとっては重大な変更ではありませんが、並列化できない「OneTimeSetUp」の並列実行にすでに依存している人々にとっては重大な変更です。

3. フィクスチャレベルのOneTimeSetUpは、複数回実行されるようになりました。 これにより、1回限りのセットアップによる効率の向上がなくなり、場合によってはセマンティクスが変更される可能性があります。 特に、初期化が何らかの形でグローバル状態に影響を与えた場合（データベースのセットアップなど）、エラーが発生する可能性があります。 これは私には容認できない破損のように思えます。

この思考実験は、フィクスチャのテストケースごとのインスタンス化を実装する方法を考えるのに役立つことがわかりました。 NUnit 3で導入された場合は、明らかに新しいデフォルト以外の機能である必要があります。NUnit4またはその他の新しいフレームワーク（TestCentricなど）の場合、新しい動作が簡単にデフォルトになる可能性があります。

注意として、MSTestのTestClassとTestMethodをそれぞれTestFixtureとTest置き換えるだけで、NUnitとMSTestのセマンティクスが異なることがわかりました。 MSTestは、テストごとに新しいインスタンスを作成します。これを読んでいるすべての人が知っていると思いますが、NUnitはTestFixtureインスタンスを再利用します。

この移行を容易にするために、 TestFixture(lifeCycle = OneTestPerInstance)]などを記述できれば便利です。

_edit：_実際、 Setupメソッドを使用するようにテストを移植したところ、既存のコードイニシャライザー/ビフォア/ティアダウンコードがMSTestの下でかなり拷問され、現在は単純なプロパティイニシャライザーコンストラクターであることがわかりました。ずっと良くて完成度が高いので、翻訳してよかったです。 それでも、互換性の問題として、持っているといいでしょう。

@CharliePoole

順序付けを使用し、あるテストによって行われた状態の変更に依存して他のテストに影響を与えるテスト。

ああ、はい、壊して、これらのテストを破ってください、かなりお願いします!!! 🤣それは私が考えることができるユニットテストフレームワークの最悪の悪用です。

フィクスチャレベルのOneTimeSetUp

ええと、私はいつもこれがプロセスごとに一度実行されると思っていました...私はいつもそれが静的ではないのはなぜだろうと思っていました。

しかし、ええ、パフォーマンスも非常に有効なポイントです。

この機能は2年以上前から議論されていますが、不快に思われるわけではありませんが、近い将来に実際に実装するための具体的かつ現実的な計画はありますか？

私のチームが別のフレームワークへの移行を計画する必要があるのか​​、それとも今後数か月以内に解決されるのか、この問題は私たちにとって目を見張るものであるため、知りたいと思います。

これはテストの実行方法に対する大きな変更であり、現在の機能に依存している人を完全に壊さないように、完全な影響を考慮する必要があります。

これを「解決」する最良の方法は、テストクラスのスレッドを安全にすることです。 他の優れたマルチスレッドアプリケーションと同様に、スレッドセーフが最優先されます。
たとえば、setupメソッドでセットアップしてから、多くのテストメソッドで使用するフィールドを使用している場合、クラスはスレッドセーフではありません。 それはNUnitの欠陥ではありません。 スレッドセーフではないシングルトンを作成しました。

TestFixture内にサブクラスを作成して、各テストの一部として作成するコンテキスト情報を保持することで、シングルトンTestFixtureがスレッドセーフであることを確認します...したがって...問題を「解決」します。
したがって、「別のフレームワークへの移行」に時間を費やすのではなく、シングルトンTestFixturesをスレッドセーフにするためにその時間を費やしたことをお勧めします。

たとえば、NUnit TestFixtureがシングルトンであるという事実に最初に遭遇したとき、500を超えるテストを含む100以上のテストフィクスチャをスレッドセーフに変換しました（RhinoMocksもスレッドセーフではないため、RhinoMocksからMoqに移動する必要がありました）。私は約4週間です（正直なところ、Rhino-> Moqはその時間のほとんどを費やしました！）

原則として100％正しいですが、7000以上の単体テストの既存のテストスイートがある場合、スレッドセーフになるように書き直すだけでも莫大な投資になります。

別のフレームワークに移行するよりも投資が多いかどうかはわかりませんが（それを自動化するツールがあるかもしれません）、この機能要求は原則として破棄されるべきではないと思います、IMO

私はこの機能を見るべきではないと主張していません。

しかし、nunitの動作方法に対するこのような大きな変更は、下位互換性（非常に難しい場合があります）または新しいメジャーバージョン（これも小さな作業ではありません）のいずれかについて検討する必要があります。

nunitのユーザーがスレッドセーフでマルチスレッド環境で実行できるようにコードを作成する方が、より簡単なアクションの形式であることをお勧めします。 あなたはおそらくそれをスクリプト化することさえできます。

私はこのリポジトリの寄稿者ではないので、それがどのように実装されているかについてのコンテキストはありません。 そのため、これは信じられないほどナイーブかもしれませんが、これをオプションのスイッチとして実装することはできませんか？ これが何も壊さないように？

この全体の問題は、オプションのスイッチを実装できるさまざまな方法について説明しています...多くの方法があります

これは、完全にボランティアによってスタッフが配置されたオープンソースプロジェクトです。 機能が受け入れられると、これまでどおり、チーム内または外部の誰かがそれを取得して実行するのを待ちます。 誰にでも仕事を割り当てる「上司」はいない。 それを成し遂げるために専念する時間がなければ、誰もそれをしなかったのは実際には良いことです。 そうすれば、それを実行する能力があり、興味を持っている人なら誰でも利用できます。

PRはいつでも歓迎しますが、NUnitの他の多くのことを壊す可能性があるため、これはおそらく誰かにとって初めての貢献ではありません。 とにかく私の意見。

私はこれまでほど積極的に貢献しなくなったので、それをどのように行うべきかについての私のコメントは、それを手にした人へのアドバイスとして与えられました。

私はそれがしばらくの間存在していたことに同意します、そして私はそれが自分で行われるのを見たいです。

@BlythMeisterスイッチはそれを少し単純化し

確かに、それはスイッチですが、電球をオンにするだけではありません。 ラジオをAMからFMに切り替えるようなものです...まったく新しい回路が登場します。

この場合、関係するのはテストの実行におけるまったく新しいライフサイクルであるため、かなりの量のコードを置き換える必要があります。 小さなことではありません。 リスクは、新しい「回路」が古いものに影響を与えないようにすることにあります。

申し訳ありませんが、「スイッチ」が単純ではない理由について、私の説明はあいまいでした。

@BlythMeister私は実際にあなたが説明したことを正確に実行しました-テスト中に状態を追跡し、テストが完了した後にそれを

テスト結果を使って何かをすることは、TearDownが私たちが設計したものではないことを覚えておくと便利です。 もちろん、多くの人がそれをそのように使用していることを知っており、動機を理解していますが、TearDownがテストの一部であり、それが終わるまで終わらないという事実に本質的に帰着するトリッキーなコーナーケースがたくさんあります。

NUnit 3では、エンジン拡張機能を使用してフレームワークの外部で結果を調べるユーザーが増えることを期待していましたが、テスト自体の中での作業はより馴染みがあり、アクセスしやすいようです。

@CharliePoole

1. フィクスチャレベルのOneTimeSetUpは、複数回実行されるようになりました。 これにより、1回限りのセットアップによる効率の向上がなくなり、場合によってはセマンティクスが変更される可能性があります。 特に、初期化が何らかの形でグローバル状態に影響を与えた場合（データベースのセットアップなど）、エラーが発生する可能性があります。 これは私には容認できない破損のように思えます。

テストケースごとのインスタンス機能を実装できず、OneTimeSetUpを1回だけ実行できないのはなぜですか（メインスレッドがそれを呼び出すことを忘れないでください）。

これは、インスタンスを初期化した既存のOneTimeSetUpを壊してしまうためです。これは非常に一般的です。

これは、スイッチベースのソリューションの問題だと思います。 テストフィクスチャのまったく新しい代替案を定義すれば、それほど問題にはなりません。これは、私が非常に魅力的だと思うアプローチです。

これは、インスタンスを初期化した既存のOneTimeSetUpを壊してしまうためです。これは非常に一般的です。

「テストケースごとのインスタンス」機能が有効になっている場合に、静的なOneTimeSetUp OneTimeTearDownメソッドと

このGithubの問題の主な動機は並列化ですが、「驚き最小の原則」と「互いに影響し合うテストによって引き起こされるエラーの回避」も動機として取り入れたいと思います。 （他の誰かがすでにこれについて言及していることを見逃した場合はお詫びします。）

このかなり古いスレッドで十分に読み返していない場合、私のコメントはこの機能に反対するのではなく、提案された特定の実装に反対します。 TestFixtureを、動作が異なるまったく新しいタイプのフィクスチャに置き換えることを好みます。

ここでは驚き最小の原則がうまく機能していると思います。 新しいフィクスチャの動作が異なっていても驚くことではありません。

一方、既存のフィクスチャを制御するフラグを作成する場合、現在の実装でそのフラグを分岐する必要がある5つまたは6つの異なる場所を考えることができます。

これは、2つのフィクスチャタイプが特定のコードを共有しない可能性があるということではありません。 しかし、それはユーザーの視野の外になります。

@fschmiedところで、新しいフレームワーク（またはNUnit 4）を実行している場合は、

TestFixtureを、動作が異なるまったく新しいタイプのフィクスチャに置き換えることを好みます。
[...]
ここでは驚き最小の原則がうまく機能していると思います。 新しいフィクスチャの動作が異なっていても驚くことではありません。

もちろんその通りです。 私が言いたかったのは、元の種類のテストフィクスチャの場合、動作はほとんどの人にとって依然として驚くべきものであるということです。 （2週間前、別のテストに影響を与えるテストのケースを見つけた同僚を驚かせました。彼は2013年からNUnitを使用しているため、この問題を調べました。）

しかしもちろん、それは下位互換性、実装の複雑さ、そして原罪を正したいという願望の間のトレードオフです[1]。

OneTimeSetUpの問題に戻る：テストフィクスチャクラスがテストごとにインスタンス化されている場合でも、テストフィクスチャごとにOneTimeSetUpを設定することは依然として重要だと思います。 OneTimeSetUpがインスタンスの状態を操作する場合の混乱を避けるために、テストごとのインスタンス機能を使用してOneTimeSetUp （およびOneTimeTearDown ）を静的に強制することを提案します。 （スイッチとして実装されているか、新しい種類のテストフィクスチャとして実装されているかは関係ありません。）

[1] James Newkirkがこれを書いた：

NUnit V2.0を作成したときに発生した最大の問題の1つは、含まれているテストメソッドごとにテストフィクスチャクラスの新しいインスタンスを作成しないことでした。 私は「私たち」と言いますが、これは私のせいだと思います。 各テストメソッドのテストフィクスチャの新しいインスタンスを作成するためのJUnitの理由を完全には理解していませんでした。

しかし、彼はこれも書いています：

[...] NUnitの動作方法を変更するのは難しいでしょう、あまりにも多くの人が不平を言うでしょう[...]

:)

はい、ジムと私はこれについて何年も議論してきました。 ：smile：私たちが同意することの1つは最後の文です。 ジムは、彼の好みのアプローチを実装する前に、新しいフレームワークを実行するために出発しました。 私は基本的に同じことをしていますが、SetUp / TearDownは私が異なる方法で行う可能性が高いことの1つです。

かなり経験豊富なNUnitユーザーの多くが、すべてのテストケースで同じインスタンスを使用していることに気付いていないことに驚いています。 NUnitが最初に登場したときは、JUnitとの明らかな違いであったため、より広く知られていました。 今ではそれはすべて忘れられており、新しい人々はNUnitが一致しないことを期待してNUnitにやって来ます。 考えるべきこと。

だから..これは手に入れるためですか？ それともまだ設計段階ですか？

現在、.NETでは、TestContextを使用しないXUnitまたは定型的な並列テストを使用するNUnitのいずれかを使用しています。

この機能は受け入れられ、通常の優先度が割り当てられます。 誰もそれに割り当てられておらず、マイルストーンにリストされていません。 つまり、誰かがそれに取り組みたいと決める必要があるということです。 それはコミッターまたは寄稿者である可能性があります。

私たちは通常、設計段階を行いません-必要に応じて、設計ラベルが適用されます-しかし、そうであっても、それを実装する方法、特にそれがどのように見えるかを説明するコメントを投稿することをお勧めしますユーザー。 それをコーディングすることから始めた場合、とにかく設計の議論に終わる可能性があるので、最初にそれを乗り越えるのがおそらく最善です。

それで、あなたはそれに取り組みたいですか？

確かに、私はちょうどで働き始めました
https://github.com/avilv/nunit/tree/instance-per-test

このコードベースは初めてなので、できる限り元のコードスタイルに固執しようとしています
これまでのところ、 InstancePerTestCase属性を導入し、アセンブリおよびクラスレベルでサポートすることを計画しています。

ここで基地から離れているかどうか教えてください

前回のコミットで、いくつかの実装の詳細についてコメントを追加しました。

デザインに関しては、 IApplyToContextから派生した属性は理にかなっていると思います。 私はInstancePerTestCaseよりももっと一般的なものを好むと思います

C# [FixtureLifeCycle(LifeCycle.InstancePerTestCase]

これにより、アセンブリレベルで設定し、個々のフィクスチャでリセットすることができます。

CharliePooleあなたは多すぎます、フィードバックと助けに感謝します

私は物事がどのように構築されているか/何が何をしているのかなどをゆっくりとしかし確実に理解していると思います

これがライフサイクル列挙型の私の提案です（私もあなたの提案で私のブランチを更新しました）

    /// <summary>
    /// Specifies the lifecycle for a fixture.
    /// </summary>
    public enum LifeCycle
    {
        /// <summary>
        /// A single instance is created and for all test cases.
        /// </summary>
        SingleInstance,

        /// <summary>
        /// A new instance is created for each test case for fixtures that are marked with <see cref="ParallelizableAttribute"/>.
        /// </summary>
        InstancePerTestCaseForParallelFixtures,

        /// <summary>
        /// A new instance is created for each test case.
        /// </summary>
        InstancePerTestCase
    }

@ jnm2このアプローチについてどう思いますか？InstancePerTestCaseForParallelFixturesについては少し不確かですが、これは最初の実装には少し多すぎるかもしれません。 いつものように、一度実装されると、私たちはそれに固執します。

並列処理との結びつきを__do__受け入れる場合、属性ベースではなく、コンテキストベースである必要があります。 つまり、任意のテストを並行して実行できるため、 `InstancePerTestCaseWhenCasesAreParallelに似ています。 並列フィクスチャは、この機能を特に必要としません。 そして多分それはユーザーに決定を任せたほうがよいでしょう。

また、並列処理と組み合わせてはならないことにも同意します。 並列処理がこの機能を追加する理由でしたが、この機能が有用であることに同意したら、私の意見では、コードに反映されるべきではありません。

同意します。NUnitの現在のデフォルトモデルがあなたを噛むので、並列シナリオでのみ使用するユースケースを理解していますが、これが将来のデフォルトのライフサイクルになることを願っています（nunit 4？）最初からこのようでした

おそらく、SingleInsance / InstancePerTestCaseのままにしておく必要があります

もう1つの質問は、ここでIDisposableパターンを処理する必要があるかどうかです。これにより、SetUp / TearDownが冗長になりますが、XUnitスタイルの方がはるかに自然に感じられます。

IDisposableを実装するテストフィクスチャはすでに廃棄しています。 あなたはそれが機能し続けることを確認する必要があります。

素晴らしい、します。

おそらく今日からテストケースの追加を開始しますが、そのようなコアメカニズムであるため、InstancePerTestCaseがオンのときに同じことが機能することを確認するケースがかなり追加される可能性があります。間違っている場合は、修正してください。

DisposeFixtureCommandは、Disposeの呼び出しを処理します。

IMOの主な問題は、テストフィクスチャのコマンドストリーム全体が__テストごとに__呼び出されるようにすることです。 私がこれまでに見た変更は、仕事をしているように見えるコマンドストリームを正しく作成しますが、重要な問題は、テストケースごとに確実に呼び出されるようにする方法です。 （フィクスチャのコマンド構造はテストケースのコマンド構造とは異なることに注意してください。）compositeworkitemはコンテキストに敏感であり、コマンドを正しく呼び出す必要があると思います（これまでのように）が、チャンスが得られるかどうかはわかりません__every__テストケースに対してそうします。 （私はコードを読んでいるだけなので、間違っている可能性があります。）

@CharliePooleはあなたが正しいように見えます、私はテストメソッドを正確に実行するものについて少しグラフを作成しました：

現在、RunChildrenループでテストオブジェクトインスタンスを作成していますが、他に見逃したラッパーがある場合や誰かが新しいラッパーを必要としている場合は言うまでもなく、Retry / Repeatコマンドには十分ではありません。
TestMethodCommandにはるかに近い必要があります

最新の変更を更新しました
https://github.com/avilv/nunit/tree/instance-per-test-2

InstancePerTestCaseWhenCasesAreParallelを削除しました
SimpleWorkItemでMakeTestCommand内部コンストラクト/廃棄固定具を添加し、CompositeWorkItem MakeOneTimeSetUpCommandでそれをスキップ介しFixtureLifeCycleを実装

それはうまく機能しているようで、フレームワークがどのように構築されているかもより理にかなっています
今、私はすべてが正しく機能していることを確認するためにたくさんのユニットテストを追加する必要があります

次のバージョンの前にこれがレビューされる可能性はありますか？ もちろん、改善/変更のためにまだ準備中です

このアプローチは私には良いと思います。それができれば、次のリリースで使用したいと思います。

これをレビューしてもらうチャンスはありますか？ 本当に近づいてきたような気がします

この機能に何か動きがあったかどうか知りたいですか？ @avilvがかなり近づいたようです。 長い間このような機能を期待していて、それを使うことに興奮しています！

皆さんありがとう！

この機能は現在機能していますか？

@CharliePoole @avilvの最新バージョンを確認して

@janissimsons申し訳ありませんが、私はもうこのプロジェクトに参加していないので、私のレビューはそれを前進させません。 @ nunit-framework-team誰かがこれをレビューできませんか？

＃ 3427をマージするために行われたすべての作業に感謝します。

新しい機能をどのように使用しますか？ 誰かが新しい属性とそれらを適切に使用する方法について簡単な説明を書くことができますか？

今後数週間でリリースする予定です。 まで待ちたかった。 NET 5は最終版であり、リリース前にNET5で少し最終テストを行います。 何か問題はないと思いますが、近すぎて待つほうがいいと思いました。

@rprouse新しいバージョンをリリースする予定の見積もりはありますか？ この機能を使い始めたいのですが。

@janissimsonsすぐに。 .NET 5.0ビルドに関するいくつかの問題と他のいくつかの問題を解決しているので、リリースします。 このプロジェクトボードでステータスを追跡できます、

これは素晴らしいニュースです！

これにより、NUnitで次のことが可能になることを正しく理解していますか？

これらすべてを組み合わせる：

• テストはパラメータ化されます
• テストを並行して実行します。
• 同じテストのパラメーター化されたバリエーションを並行して実行できます。
• テストはデータ駆動型にすることができます

ここで過去にいくつかのことを試しましたhttps://github.com/jawn/dotnet-parallel-parameterized-tests

新しいリリースは、.NET Full Framework 4.7.2または少なくとも4.8と引き続き互換性がありますか？

よろしくお願いします、
DR

@jawnはい、すべて

@drauchはい、3.13リリースは引き続き

@avilvお疲れ様でした!!
ちなみに、どのツールを使用して、その素晴らしいフロー図を作成しましたか？
ありがとう

@rprouseこの新機能の使用方法に関するドキュメントも更新して

@janissimsonsリリースのドキュメントを更新する予定です。 ただし、短いバージョンでは、おそらく[Parallelizable(ParallelScope.All)]とともに[FixtureLifeCycle(LifeCycle.InstancePerTestCase)]をテストクラスに追加すると、クラス内で実行されるテストごとにテストクラスのインスタンスがインスタンス化されます。 これにより、他のテストで変数が変更されることを心配せずに、クラス内のメンバー変数を並列テスト実行で使用できるようになります。

@LirazShayスクリーンショットの図は、Visual https://docs.microsoft.com/en-us/visualstudio/modeling/map-dependencies-across-your-solutionsReSharperにも同様の機能があります。

@ jnm2どうもありがとう!!!
私はVSエンタープライズを持っていますが、非常に役立つこの機能について知りませんでした
ヒントありがとうございます

これがリリースされ、3.13リリースの一部であることは正しいですか？

これがリリースされ、3.13リリースの一部であることは正しいですか？

特に＃3720のアセンブリレベルの属性アプリケーションに関して、いくつかの問題が観察および修正されたと思います。現在、3.13.1を待っています。

NUnit3.13.1がリリースされました。
これ以上の問題は残っていますか？

いいえ、それが閉鎖された理由です@andrewlaser