Nunit: 테스트 케이스별 인스턴스 기능

현재, (1) 생성자 또는 일회성 설정에서 상태를 설정하고 (2) 어떤 테스트에서도 변경하지 않는 병렬 테스트 간에 상태를 공유할 수 있습니다. 상태가 테스트 또는 설정에서 상수로 설정된 경우 다른 값으로 설정하지 않는 한 어떤 경우에는 통과할 수도 있습니다. 우리가 그것을 수행하는 일부 NUnit 테스트가 있다고 생각하지만 후자는 icky입니다.

제 생각에는 기본값을 조만간 변경할 수 없다고 생각합니다. 변경 가능한 상태가 있다고 해서 현재 버그가 보장되는 것은 아닙니다. 실제로 변경하면 버그일 뿐이며 코드 분석을 하지 않는 한 알 수 없습니다.

테스트 또는 설정 또는 분해 내에서 인스턴스 상태를 변경하지 않으면 손상되지 않습니다. 그렇게 하면 테스트가 자체적으로 병렬로 실행될 수 있는 한 이미 고장난 것입니다. 내가 생각할 수 있는 당신이 부서지지 않을 방법은 없습니다. 그것이 사용자의 복잡성이 "합리적인 기본값" 결과의 가치가 있다고 생각하는 경우 자동 옵션에 대한 정당화입니다.

당신은 요점이 있지만 나는 이것이 우리가 지금 결정할 필요가 없는 잠재적인 연장이라고 계속 옹호할 것입니다. 지금 모든 결정을 내리려고 하지 말고 이 작업을 반복적으로 수행해 보겠습니다.

저는 @CharliePoole 과 함께

모든 스레드에 대해 공유되는 인스턴스가 아니라 스레드당 인스턴스를 트리거하는 고정 수준 속성일 수 있습니다.

@BlythMeister 걱정하지 마세요! 기존 코드가 손상되기 시작할 수 있는 변경 사항은 고려하지 않습니다.

이건 재미 있네. 나는 instance-per-test-case가 instance-per-thread보다 마음을 감싸는 것이 더 쉽다고 생각합니다. 테스트가 스레드에 할당되는 방식은 신뢰할 수 없으므로 인스턴스당 테스트 케이스에 비해 어떤 이점이 있는지 생각할 수 없습니다.

네, 병렬 실행을 의미하기 위해 스레드라는 용어를 사용하고 있습니다. 이것은 사실 정확하지 않습니다.
죄송합니다.

XP의 관점에서(그리고 모두가 그것이 항상 내 관점이라는 것을 알기를 바랍니다) 서로를 기반으로 하는 세 가지 이야기가 있습니다...

1. 사용자는 어셈블리의 모든 고정 장치에 대해 전역적으로 테스트 케이스당 인스턴스 동작을 지정할 수 있습니다.

2. 사용자는 픽스처에서 테스트 케이스당 인스턴스 동작을 지정할 수 있습니다.

3. 사용자는 병렬로 실행될 수 있는 테스트를 포함하는 고정 장치에 대해 테스트 케이스당 인스턴스 동작을 지정할 수 있습니다.

이 문제에서 (1)이 완전히 구현되는 것을 보고 싶습니다. 당분간은 (2)를 머리에서 빼야 한다고 생각합니다. 또는 적어도 코드를 작성하는 부분에서는 제외해야 합니다. (3)은 가능성이 있다고 생각하지만 다른 문제에서 이미 접한 몇 가지 함정이 있습니다. (픽스쳐는 테스트 케이스가 병렬로 실행되는지 여부를 알지 못합니다!) (1)과 (2)가 완료되고 병합된 후의 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
+   }
}

이에 대한 내 생각은 적어도 새로운 프레임워크의 맥락에서 약간 변경되었습니다.

이제 각 동작에 대해 하나씩 두 개의 클래스 수준 속성이 있어야 한다고 생각합니다. TestFixture가 테스트당 인스턴스와 작동하도록 하고 Shared Fixture가 현재 NUnit처럼 작동하도록 합니다. 분명히 이것은 NUnit의 맥락에서 획기적인 변경이지만 일반적인 접근 방식은 고려할 가치가 있습니다.

@CharliePoole [TestFixture(FixtureOptions.PerTestCase)] 좋은 구문처럼 보이지만 어셈블리 수준 속성도 강력하게 원하므로 모든 테스트 프로젝트에 옵트인할 수 있습니다. 어셈블리 수준 속성이 어떻게 생겼으면 합니까?

맞습니다. 그래서 저는 새로운 프레임워크에서 무엇을 할 것인지에 대해 예약 WRT를 표현했습니다. 그러나 NUnit의 경우 TestFixture 의 의미를 변경하고 싶지 않을 것이며 사례별 동작에 대해 정말 좋은 이름이 생각나지 않습니다. 두 개의 이름이 있는 경우 모든 조명기에서 원하는 동작을 얻기 위해 해야 할 일은 소스 파일의 전역 편집을 수행하는 것입니다.

어셈블리 수준의 전역 설정은 AssemblyInfo 파일에 설정된 내용을 알지 못하는 일부 개발자를 혼란스럽게 만들기 때문에 싫어합니다. 현재는 몇 개만 허용하므로 하나 더 추가해도 큰 문제는 없다고 생각합니다. 어셈블리의 모든 고정 장치에 대한 옵션(기본값?)을 설정하고 있음을 전달해야 한다는 점을 제외하고는 어셈블리 수준 속성의 이름에 대해 아무 생각이 없습니다.

나는 당신이 언급한 바로 그 이유로 어셈블리 수준의 기본값도 어느 정도 싫어합니다. 현재 속성이 없는 각 고정 클래스에 새 속성을 추가하는 것과 비교하여 어셈블리 수준 속성이 선호하는 경로입니다.

@nunit/framework-team 어떻게 생각하세요? 기능의 초기 도입:

• 예/아니오 어셈블리 수준 설정?
• 조명기 수준 설정에 예/아니요?
• 방법 수준 설정에 예/아니요?
• 예/아니오 테스트 케이스 수준 설정?

속성 없는 조명기 클래스에 대한 좋은 점입니다.

나는 예, 예, 아니오, 아니오라고 말할 것입니다

나는 Charlie의 말에 동의합니다. 'fixture-level'이 'class-level'을 의미한다는 설명에 동의합니다. (예를 들어 테스트 케이스 소스 방법과 반대입니다. 😊)

도움이 됩니다! 따라서 [TestFixture(FixtureCreationOptions.PerTestCase)] 의 문제는 동일한 클래스에서 여러 TestFixture 속성이 허용되고 서로 모순될 수 있다는 것입니다. 어셈블리와 클래스에 적용할 수 있는 새로운 명명된 특성을 갖는 것이 더 좋고 간단합니까?

```c#
[어셈블리: ShareFixtureInstances(거짓)]

[ShareFixtureInstances(거짓)]
공개 클래스 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);
+   }
}

잘 들린다. 이것의 상속 동작은 무엇입니까? 자체 테스트와 함께 기본 클래스에 특성이 있고 해당 클래스에서 상속하는 경우? 😊

아마도 '클래스' 속성이므로 문제의 테스트가 실행되는 실제 클래스에 있어야 합니까?

또한, 나는 그 이름에 완전히 관심이 없습니다. 고정 장치가 항상 단위 용어로 클래스가 아니기 때문에 (예: testcasesource의 모든 테스트 - 'suite'와 'fixture'가 더 강력한 의미를 갖지 않는 한) 생각하지 않습니다. Nunit 용어로 생각보다 의미!)

InstancePerTest의 라인을 따라 ...하지만 더 나은 이름을 가진 것은 어떻습니까?

어셈블리 및 클래스 수준에 대해 동의했지만 더 이상은 아닙니다. 나는 또한 @ChrisMaddock 의 제안 ClassInstancePerTest(bool) 라인을 따라 무언가를 선호합니다. 또한 클래스 수준의 특성이 어셈블리 수준을 재정의하고 상속될 것으로 예상한다고 가정합니다. 상속은 일반적으로 병렬 처리와 결합된 클래스의 구성원을 기반으로 하는 테스트당 인스턴스를 원하기 때문에 중요하다고 생각합니다. 따라서 파생 클래스에 자동으로 적용되기를 원할 것입니다.

테스트 픽스처 유형이 구성 가능한 경우 NUnit이 테스트당 인스턴스를 생성하지 않는다는 사실에 정말 놀랐습니다. 저는 항상 단위 테스트를 잘 모르겠습니다. 단위 테스트를 생각했습니다. 스캐폴딩을 설정하고 테스트를 실행하면 스캐폴딩이 사라집니다. 테스트 간에 의도하지 않은 상태 전송이 없습니다.

그것을 배웠습니다. @jnm2 와 마찬가지로 테스트를 수동으로 인스턴스화합니다. 그러나 테스트가 예를 들어 파일을 생성하고 삭제할 때 케이스 러너는 정말 복잡해집니다. IDisposable이어야 합니다. 더 이상 마법 같은 [TearDown] 는 없습니다. :( 스캐폴딩 오류에서 테스트 오류를 ​​구별하는 일관된 방법도 없습니다. 이것은 정말 고통스러운 사용 사례입니다.

디자인에 끼어들 수 있다면 @CharliePoole 과 함께 yes, yes, no, no입니다.

PerTestInstance , InstancePerTest 또는 이와 유사한 이름이 ShareFixtureInstances 보다 훨씬 낫습니다. 나는 F# 코드를 테스트할 때 유형 인스턴스가 클래스 라고 생각하지 않기 때문에 속성 이름에 Class 라는 단어를 약간 싫어합니다. 하지만 내가 그걸로 살 수 있다는 것은 확실합니다! :)

오, 이 기능이 기대됩니다!

@kkm000 "class" 사용에 동의합니다. NUnit은 일반적으로 구현과 구별되는 이름을 사용했습니다. 그때도 사람들은 추측을 하지만 그런 일은 피하는 것이 일관성이 있는 것이 좋다.

내가 말하는 것의 예: Test, TestFixture, SetUpFixture, Worker(스레드 아님) 등. 원칙적으로 __could__ 클래스는 고정 장치가 아닌 단일 테스트를 나타냅니다... 우리가 그렇게 하거나 심지어는 해야 하지만 __할 수 있습니다__.

@kkm000

댓글 감사합니다! 당신은 전혀 끼어들지 않습니다. 우리는 가능한 한 언어에 구애받지 않는 디자인 목표를 가지고 있습니다.
C#에 초점을 맞추는 것 외에 class 라는 단어에 대한 또 다른 점은: 언젠가 우리가 클래스가 아닌 설비를 지원한다면?

[InstancePerTestCase] 는 문제를 회피하지만 직관적인 명확성을 잃을 수 있습니다.

오늘날 비품과 클래스는 크게 다르지 않지만 만약 그들이 갈라진다면 이 속성은 클래스가 아닌 고정물과 관련이 있다고 확신합니다.

스위트는 일반적인 조직 개념인 반면 고정 장치는 설정/해제 논리 및 테스트 상태를 보유하고 테스트 메소드에 전달되는 것입니다(현재 인스턴스 메소드의 this 인수로). 설비가 조직 계층의 일부일 필요는 없습니다. 클래스의 개념에서 벗어나고 테스트 스위트의 개념에서 벗어나는 픽스처를 상상해 봅시다.

```c#
public static class SomeTestSuite // 고정 장치가 아님: 설정/해제 논리 및 테스트 상태 없음
{
[Test] // 매개변수화된 스위트가 아닌 단일 테스트;
// 고정물은 암시적 this 매개변수 대신 매개변수를 통해 주입됩니다.
공개 정적 무효 SomeTest(SomeFixture 고정 장치)
{
고정.SomeService.SomeProperty = true;
고정.SomeAction();
고정.AssertSomething();
}
}

[테스트픽스처]
공개 구조체 SomeFixture : IDisposable
{
공개 SomeService SomeService { 가져오기; } // 상태

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 가 있는 또 다른 속성)로 장식하는 것이므로 다음과 같이 보입니다. Fixture라는 단어를 사용하는 _consistent_ 옵션.

(토론해야 할 중요해 보이는 요점을 가져오고 있지만 이름이 무엇인지에 대해서는 별로 관심이 없습니다.)

@jnm2 Suite와 Fixture의 개념을 분리할 수 있다는

내가 아는 한 xunit.net은 픽스처를 테스트 상속 계층 구조에서 분리된 엔터티로 만든 최초의(유일한?) 프레임워크였습니다.

매개변수화된 테스트를 만들 때 TestCaseSource를 별도의 "픽스처"로 도입할 수 있었습니다. 나는 그렇게 하지 않았고 다시 실행하기 위해 필요한 변경 사항이 지금 깨질 것이라고 생각합니다.

사람들이 가끔(병렬화 이전에) 사례별 동작에 대해 묻는 이유는 다른 프레임워크가 하는 일이기 때문입니다. 비슷한 이유로 그들은 분리 가능한 비품을 요구하지 __하지 않았습니다__.

결론적으로 제 생각은 이렇습니다...

1. 테스트 케이스 동작마다 인스턴스가 필요합니다.

2. 이전 버전과의 호환성 때문에 기본값이 될 수 없습니다.

3. 분리 가능한 고정 장치는 멋진 아이디어이지만 별개의 문제이기도 합니다.

4. 분리 가능한 고정 장치는 최소한 인스턴스 고정 장치만큼 구현하기가 복잡해 보입니다. 물론 이 경우 이전 버전과의 호환성을 처리할 필요가 없으므로 더 쉽습니다.

3번과 4번 항목에 대해 확인하기 위해 코드 샘플을 새로운 기능에 대한 제안이 아니라 이 속성에 대한 올바른 이름을 찾는 데 도움이 되는 사고 실험으로 의도했습니다. 사고 실험은 우리가 지금 우연히 일치하더라도 클래스나 스위트가 아니라 고정 장치의 아이디어에 정말로 집중하고 있음을 알려줍니다.

어떤 형태를 취하든 조명기는 설정/해체/상태의 재사용 가능한 정의입니다. 나는 그것이 단어의 의미라고 믿습니다. Fixture instance(setup/teardown/state의 발생)는 우리의 새로운 속성이 테스트 케이스 간에 공유하거나 공유하지 않기로 결정하는 것입니다. 이름의 어딘가에 FixtureInstances 있으면 최대의 명료성을 얻을 수 있다고 생각합니다.

이것이 모든 사람에게 옳은 것 같습니까? 그렇지 않다면 어떤 다른 점을 고려할 수 있습니까?

아! 죄송합니다. 일반적으로 간과되는 매우 좋은 점을 지적했다고 생각했지만 우리가 빗나간 것은 아닐까 걱정도 됩니다. :약간_찡그린_얼굴:

전체 이름(무엇을 입력하든지)에는 Fixture와 Instance가 모두 포함되어야 한다고 생각합니다. 수행 방법은 속성 이름 또는 구성에 사용된 열거형에 대해 이야기하고 있는지 여부에 따라 다릅니다. 둘 중 하나에 정착했는지 확실하지 않습니다.

네, 좋은 지적입니다.

열거형을 하면 입력하는 시간이 길어집니다. 이것은 어셈블리 대상 속성보다 클래스 대상 속성에 더 중요합니다. 동일한 클래스에서 여러 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(거짓)]
클래스 SomeFixture
{
}
```

장점: 잘못된 상태는 표현할 수 없습니다.
장점: 오해하기 어렵습니다(하지만 저는 신규 사용자가 아니기 때문에 여기에 맹점이 있습니다)
단점: 긴 이름
아마도 con: 옵션과 값을 모두 지정할 수 있는 매우 구체적인 이름입니다. (하지만 내가 좋아하는 [NonParallelizable] 도 있습니다.)

(대체 제안 환영합니다!)

어셈블리에 대한 속성과 클래스 자체에 대한 속성이라는 두 가지 속성이 있어야 합니다.

장점: 컨텍스트에서 다른 동작을 가진 하나의 속성보다 두 개의 간단한 속성을 구현하는 것이 더 쉽습니다. (ParallelizableAttribute에서 배운 교훈)
장점: 각각의 이름을 적절하게 지정할 수 있으므로 사용자가 더 쉽게 이해할 수 있습니다. 예를 들어 어셈블리 수준에는 "기본값"이라는 단어가 포함될 수 있습니다.
단점: 기억해야 할 두 가지 속성.

각각의 대안을 사용하여 접근:

```C#
[어셈블리: DefaultFixtureOptions(InstancePerTestCase = true)]

[FixtureOptions(InstancePerTestCase = false)]
클래스 SomeFixture
{
}

[어셈블리: DefaultFixtureOptions(FixtureCreationOptions.PerTestCase)]

[FixtureOptions(FixtureCreationOptions.Singleton)]
클래스 SomeFixture
{
}

[어셈블리: DefaultFixtureInstancePerTestCase]

[FixtureInstancePerTestCase(거짓)]
클래스 SomeFixture
{
}
```

기타 의견:

• 나는 C보다 A와 B를 더 좋아한다
• 공유 조명기 동작을 "싱글톤"이라고 부르면 안 됩니다. 왜냐하면 그것이 하나가 아니기 때문입니다. :smile: 상속을 받으면 기본 설비의 여러 인스턴스를 얻게 됩니다.
• 어셈블리와 조명기 수준에서 별도의 속성을 사용하는 경우 실제로 조명기 수준에서 이름에서 조명기를 삭제할 수 있습니다.
• 우리는 SetUpFixtures가 이것에 어떻게 맞는지 지정하지 않았습니다. 문제가 있으며 속성이 사용되는 경우 런타임 오류가 필요할 수 있습니다. 사실, 완전히 분리된 속성의 한 가지 장점은 우리가 이것을 다룰 필요가 없다는 것입니다. (또한 TestFixture, BTW의 속성에 대한 장점입니다)
• 우리는 사람들에게 테스트 케이스당 인스턴스가 정적 클래스에 적용되지 않는다는 것을 경고해야 합니다. 그것은 우리 모두에게 분명하지만 즉시 이해하지 못하는 사람들이 있습니다.

BTW, 나는 종종 어셈블리 및 고정 장치 수준에 대해 DefaultTestCaseTimeOut을 사용하고 Timeout을 메서드로만 유지했으면 했습니다.

좋습니다. 이러한 가능성을 제시해 주셔서 감사합니다.

지금 저를 괴롭히는 것은 우리가 이 방향으로 가고 있지 않더라도 이것이 이론적으로 의미가 있을 수 있다는 것입니다.

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

이것이 실제로 실행되는 레벨은 조명기 레벨 자체가 아니라 테스트 케이스 레벨이기 때문입니다.
예를 들어 파생된 픽스처는 기본 픽스처의 설정을 재정의할 수 있지만 실제로 하는 일은 파생된 클래스에 의해 생성된 각 테스트 케이스의 설정에 영향을 미치는 것입니다.

또는:

```c#
[어셈블리: DefaultFixtureOptions(InstancePerTestCase = true)]

// 이것이 기본값으로 간주되어서는 안 되는 이유는 무엇입니까?
[DefaultFixtureOptions(InstancePerTestCase = true)]
공개 추상 클래스 BaseFixture
{
}

공개 봉인 클래스 SomeFixture : BaseFixture
{
}
```

Default 를 사용하지 말아야 할 때와 사용하지 말아야 할 때에 대한 근거는 어떻게 찾나요?

각 테스트 케이스에서 이 속성을 구현하면 작은 이점으로 많은 복잡성이 도입될 것이라고 생각합니다.

"일반" 테스트 픽스처의 경우 테스트 픽스처와 연결된 명령 체인의 일부로 인스턴스를 계속 인스턴스화합니다. 테스트별 픽스처의 경우 인스턴스화하지 않고 테스트 체인의 일부로 새 명령을 구현해야 합니다. 이 명령은 현재 픽스처 체인에서 수행되는 것과 거의 동일한 작업을 수행합니다.

고정 장치에 두 가지 유형의 테스트가 모두 포함될 수 있는 경우 각 모델에 대해 한 번씩 두 번 실행해야 합니다.

사용자가 테스트를 별도의 고정 장치로 분할하여 동일한 결과를 쉽게 얻을 수 있기 때문에 이점은 작아 보입니다. 픽스처는 결국 NUnit 아티팩트이며 사용자에게 동일한 픽스처 동작이 필요한 테스트를 동일한 픽스처에 넣도록 요구하는 것이 합리적입니다.

"기본값"을 사용하는 경우와 관련하여... 어떤 TestFixxture에서도 __not__ 사용하고 어셈블리 수준에서만 사용하는 것 같습니다. 속성은 상속 덕분에 파생된 클래스에서 실제로 발견되기 때문에 기본 클래스도 예외는 아닙니다. 따라서 베이스에서 특정 동작을 설정하는 것은 기본값이 아닙니다. 오히려 그것은 그 클래스와 그것에서 파생된 모든 것에 대한 설정입니다. 현재 상속된 속성의 모든 경우에서와 같이 모순되는 사양은 오류를 일으키거나 무시해야 합니다. 즉, 기본 클래스에 속성 A를 배치하고 파생 클래스에 B를 배치하는 것은 기본 클래스에 직접 A 및 B를 배치하는 것과 구별되지 않습니다. 사용자가 다른 작업을 수행하면 놀랄 것이기 때문에 그렇게 설계했습니다.

WRT 설정 픽스처, btw, 거기에서 인스턴스화 옵션을 지정하려면 런타임 오류가 생성되어야 한다고 생각합니다. 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] 는 더 자연스러워 보인다(그의 sesquipedalian 이름을 제외하고는, 그러나 그것은 단지 의견일 뿐이며 미학적으로 정당화될 수 없음). 하나의 속성, 하나의 특성. 아마도 이것은 매개변수나 선택적으로 설정 가능한 속성이 필요하지 않을 것입니다.

또한 사용자로서 이름이 다른 두 개의 속성이 있다는 사실이 놀랍습니다. 하나는 어셈블리 수준에서만 적용할 수 있고( DefaultSomething ) 다른 하나는 유형 수준에서만 적용할 수 있습니다(단지 Something ). . 당연히 나는 @CharliePoole 이 Parallelizable 속성에 관해 언급한 "학습된 교훈"이 무엇인지 이해하지 못하지만 , 섬의 이쪽에서 (이 사용자의 피상적인 생각에서) 수행할 위치를 배우는 한 쌍의 속성은 당혹스러워 보입니다.

@kkm000 단일 특성을 나타내는 속성에 대한 귀하의 의견에 동의합니다.

다른 수준에서 "동일한" 특성에 대해 두 가지 다른 속성을 WRT합니다. 실제로 동일하다고 생각한다면 동의할 것입니다. 하지만 그렇지 않다고 생각합니다. 예를 들어 Timeout을 사용하겠습니다.

테스트 방법에 시간 초과가 있는 경우 "이 테스트 방법은 실행하는 데 지정된 시간(밀리초)보다 오래 걸리면 시간이 초과됩니다."를 의미합니다. 그러나 Timeout이 설비 또는 어셈블리에 배치되면 "이 항목에 포함된 모든 테스트 케이스의 기본 시간 초과는 지정된 밀리초 수입니다."라는 의미를 갖습니다. 물론 그 기본값은 더 낮은 수준에서 재정의될 수 있습니다. 그런데 두 가지 별도의 구현이 있는 두 가지 다소 다른 의미. 첫 번째는 표시되는 테스트에 시간 초과를 적용합니다. 두 번째는 포함된 테스트 케이스가 발생했을 때 발견되고 기본값으로 사용되는 테스트 컨텍스트에 기본값을 저장합니다. ParallelizableAttribute도 유사하게 작동합니다.

이 특정 경우에 픽스처에 배치된 속성은 "테스트 케이스당 한 번 이 픽스처를 인스턴스화합니다."를 의미합니다. 어셈블리 수준에서 "달리 지정하지 않는 한 이 어셈블리에서 고정 장치당 한 번 테스트 고정 장치를 인스턴스화합니다."를 의미합니다.

이 특정 경우에 픽스처에 배치된 속성은 "테스트 케이스당 한 번 이 픽스처를 인스턴스화합니다."를 의미합니다. 어셈블리 수준에서 "달리 지정하지 않는 한 이 어셈블리에서 고정 장치당 한 번 테스트 고정 장치를 인스턴스화합니다."를 의미합니다.

마지막 문장에서 말을 잘못했다고 가정하면 -- "달리 지정하지 않는 한 ~픽스처~ 테스트 케이스 당 한 번 이 어셈블리의 테스트 픽스처를 인스턴스화합니다."_ 의도했습니까? 아니면 범위와 의도를 심각하게 오해하고 있습니까?

내가 사용자가 아니라고 가정하면 의미 체계는 전혀 다르게 보이지 않습니다. " 속성으로 표시된 범위 내에서 테스트당 클래스를 인스턴스화합니다." 그것은 실제로 그러한 내부 범위입니다.” 고정물이든 어셈블리이든. 내 의견이지만 두 가지 속성이 약간 혼란스러워 보입니다. 그냥 제 생각일수도 있는데 잘 모르겠습니다.

두 개의 개별 구현

유니콘과 무지개의 gedankenworld에서 구현은 사용자 대면 측면에 영향을 미치지 않습니다. 그러나 우리(당신과 NUnit의 사용자 중 한 명)는 모두 엔지니어이며 엔지니어링은 모두 타협에 관한 것입니다. 서로 다른 범위에 대해 하나의 속성을 사용하는 것이 실제로 내부적인 번거로움과 유지 관리 부담으로 이어진다면 전혀 문제가 되지 않을 것입니다. :)

결국 나에게 이것은 사소한 문제이고 나는 같은 속성에 대해 강하게 느끼지 않으며 어느 쪽이든 정렬된 속성으로 살 수 있습니다.

@kkm000 예, "테스트 케이스당 한 번"을 의도했습니다.

일련의 중첩 범위로 생각하면 이 모든 것이 완벽하게 이해된다는 데 동의합니다. 그러나 경험에 따르면 사용자는 (a) 항상 그렇게 생각하지 않거나 (b) 범위 정의를 올바르게 이해하지 못합니다.

마지막으로 중첩 클래스와 기본 클래스를 고려하십시오. 둘 다 NUnit에서 테스트 목적으로 중첩된 "범위"로 처리되지 않지만 사용자에게는 그렇게 보일 수 있습니다.

Timeout / DefaultTimeout에 대해 언급한 문제가 좀 더 심각하다는 점을 인정하겠습니다. 픽스처의 Timeout은 전체 픽스처에 타임아웃이 적용된다는 것을 쉽게 의미할 수 있지만 물론 그렇지는 않기 때문입니다. 그 문제에 대해 어셈블리의 시간 초과는 전체 어셈블리에 적용될 수 있지만 적용되지 않습니다.

이 경우 이름에 "per test case"를 사용하여 어느 쪽이든 쉽게 갈 수 있기 때문에 모호성이 덜한 것 같습니다. 나는 어쨌든 그것에 대해 일하고 있지 않다. :웃다:

생각해 보세요. Timeout이 TestCaseTimeout이라고 했다면 더 좋았을 것입니다!

[FixtureInstancePerTestCase] 1개로 만족합니다. 사용자의 정신적 부담이 가장 적은 것 같습니다.

@nunit/framework-team https://github.com/nunit/nunit/issues/2574#issuecomment -426347735에서 아래로 훑어보고 방향을 정하도록 도와주시겠습니까?

[FixtureInstancePerTestCase] 도 내가 가장 싫어하는 옵션입니다. 😄 확장성이 없다는 것이 유일한 단점입니다.

[FixtureOptions] 문제가 마음에 들지 않습니다. 너무 혼란스러운 것 같습니다. 개인적으로 어셈블리와 클래스 모두에 대해 단일 속성을 선호합니다. 이전에 Timeout 및 Parallelizable에 대해 문제를 일으킨 점에 감사드립니다. 그러나 이 속성의 이름에 "Fixture"가 있으면 덜 모호해 보입니다.

나는 개인적으로 enum 옵션이 마음에 든다고 인용했습니다. 다만 이름을 적절하게 지정하여 더 간결하게 만드는 방법을 생각할 수 없다는 점만 빼면요!

이에 대한 업데이트가 있습니까?

모든 업데이트는 이 문제에 게시됩니다.

누군가이 문제를 해결할 수 있습니까??
현재 모든 테스트 코드를 다음과 같이 래핑해야 합니다.
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 저도 이 문제에 직면 했지만 [ThreadStatic] 에서 초기화되는 테스트 전용 필드를 만들었고 제대로 작동합니다.

@dfal
좋은 해결 방법 감사합니다!

나는 이것을 좋아할 것이다. 현재 공유 상태로 인해 쉽게 병렬화할 수 없는 nunit에서 실행되는 수천 개의 테스트가 있는 기존 테스트 제품군이 있습니다. 이 옵션이 제공되면 테스트 스위트를 훨씬 더 쉽게 병렬화할 수 있습니다.

사고 실험으로 TestFixture가 작동하는 방식을 단순히 변경했다고 상상해 보십시오. 이것은 무엇을 깨뜨릴까요?

1. 순서를 사용하고 다른 테스트에 영향을 주기 위해 한 테스트에서 수행한 상태 변경에 의존하는 모든 테스트입니다. 이것은 (아마도) 독립적인 단위 테스트의 경우에 매우 나쁜 습관입니다. 우리는 항상 사람들에게 이것을 하지 말라고 경고해왔고 나는 이런 방식으로 단일 인스턴스를 갖는 것에 의존하는 테스트(물론 메시지와 함께)를 깨는 것에 신경쓰지 않을 것입니다.

2. 일회성 설정 내에서 수행되는 작업에 따라 개별 조명기 인스턴스가 병렬로 실행되지 않을 수 있습니다. 변경의 동기는 고정 장치가 병렬로 실행되도록 하는 것이기 때문에 이것은 아이러니합니다! 이것은 이미 병렬로 실행할 수 없기 때문에 기능을 필요로 하는 사람들을 위한 주요 변경 사항이 아니지만 병렬화 불가능한 'OneTimeSetUp' 이후에 병렬로 테스트를 실행하는 것에 이미 의존하고 있는 사람들에게는 중요한 주요 변경 사항입니다.

3. 모든 조명기 레벨 OneTimeSetUp 는 이제 여러 번 실행됩니다. 이렇게 하면 일회성 설정으로 인한 효율성 향상이 제거되고 경우에 따라 의미 체계가 변경될 수 있습니다. 특히 초기화가 어떤 방식으로(예: 데이터베이스 설정) 전역 상태에 영향을 미치는 경우 오류가 발생할 수 있습니다. 이것은 나에게 용납할 수 없는 파손처럼 보입니다.

나는 이 사고 실험이 픽스쳐의 테스트 케이스당 인스턴스화를 구현하는 방법에 대해 생각하는 데 유용하다는 것을 알았습니다. NUnit 3에 도입된 경우 기본이 아닌 새로운 기능이어야 합니다. NUnit 4 또는 다른 새 프레임워크(예: TestCentric)의 경우 새 동작이 쉽게 기본이 될 수 있습니다.

참고로 저는 MSTest의 TestClass 및 TestMethod 를 각각 TestFixture 및 Test 교체했으며 여기서 NUnit과 MSTest가 다른 의미를 가지고 있음을 발견했습니다. MSTest는 각 테스트에 대해 새 인스턴스를 생성합니다. 여기에서 이 글을 읽는 모든 사람들은 알고 있을 것입니다. NUnit은 TestFixture 인스턴스를 재사용합니다.

이 마이그레이션을 쉽게 하기 위해 TestFixture(lifeCycle = OneTestPerInstance)] 또는 이와 유사한 것을 쓸 수 있다면 좋을 것입니다.

_edit:_ 사실, Setup 메서드를 사용하기 위해 테스트를 포팅한 후 실제로 기존 코드 초기화 프로그램/이전/분해 코드가 MSTest에서 상당히 고초를 겪었고 이제 간단한 속성 초기화 생성자임을 알 수 있습니다. 훨씬 멋지고 완성도가 높아서 번역을 해서 기쁩니다. 그래도 호환성의 문제로 있으면 좋을 것입니다.

@찰리풀

순서를 사용하고 다른 테스트에 영향을 주기 위해 한 테스트에서 수행한 상태 변경에 의존하는 모든 테스트입니다.

아, 네, 이 테스트를 깨고, 깨주세요, 제발!!! 🤣 그것은 내가 생각할 수 있는 단위 테스트 프레임워크의 최악의 남용입니다.

모든 조명기 레벨 OneTimeSetUp

어, 나는 이것이 프로세스 당 한 번 실행된다고 항상 생각했습니다. 나는 항상 왜 정적이지 않은지 궁금했습니다.

그러나 예, 성능도 매우 유효한 포인트입니다.

이 기능이 논의된 지 2년이 넘었습니다. 불쾌하게 들릴 생각은 없지만 가까운 장래에 실제로 구현할 구체적이고 현실적인 계획이 있습니까?

우리 팀이 다른 프레임워크로의 마이그레이션을 계획해야 하는지 아니면 앞으로 몇 달 안에 해결될 것인지 알고 싶습니다. 이 문제는 우리에게 가장 중요한 문제이기 때문입니다.

이것은 테스트 실행 방법에 대한 주요 변경 사항이며 현재 기능에 의존하는 사람들을 완전히 손상시키지 않도록 전체 영향을 고려해야 합니다.

이것을 "해결"하는 가장 좋은 방법은 테스트 클래스를 스레드로부터 안전하게 만드는 것입니다. 좋은 다중 스레드 응용 프로그램과 마찬가지로 스레드 안전성이 가장 중요해야 합니다.
예를 들어 설정 메서드에서 설정한 다음 많은 테스트 메서드에서 사용하는 필드를 사용하는 경우 클래스는 스레드로부터 안전 하지 않습니다 . 그것은 NUnit의 결함이 아닙니다. 스레드로부터 안전하지 않은 싱글톤을 작성했습니다.

각 테스트의 일부로 생성한 컨텍스트 정보를 보유하는 TestFixture 내부에 하위 클래스를 생성하면 싱글톤 TestFixture가 스레드로부터 안전한지 확인하고...따라서...문제를 "해결"합니다.
따라서 "다른 프레임워크로 마이그레이션"하는 데 시간을 보내는 것보다 싱글톤 TestFixtures를 스레드세이프하게 만드는 데 그 시간을 할애했다고 제안할 수 있습니다.... 훨씬 더 빠른 연습임을 알게 될 것입니다.

예를 들어, NUnit TestFixture가 싱글톤이라는 사실을 처음 알게 되었을 때 500개 이상의 테스트가 포함된 100개 이상의 테스트 픽스처를 스레드로부터 안전하게 변환했습니다. 저는 약 4주(솔직히 Rhino -> Moq가 대부분의 시간을 소요했습니다!)

원칙적으로는 100% 옳습니다. 하지만 ~7000개 이상의 단위 테스트로 구성된 기존 테스트 제품군이 있는 경우 스레드로부터 안전하도록 다시 작성하는 것은 엄청난 투자입니다.

다른 프레임워크로 이동하는 것보다 더 많은 투자인지 확실하지 않지만(자동화하는 도구가 있을 수 있음) 이 기능 요청을 원칙적으로 폐기해서는 안 된다고 생각합니다. IMO

이 기능을 보지 말아야 한다고 옹호하는 것은 아닙니다.

그러나 nunit이 작동하는 방식에 대한 이러한 큰 변화는 이전 버전과의 호환성(매우 어려울 수 있음) 또는 새로운 주요 버전(작은 작업이 아님)을 고려해야 한다고 생각합니다.

나는 nunit의 사용자가 다중 스레드 환경에서 실행되도록 스레드세이프를 작성하는 코드를 만드는 것이 더 쉬운 형태의 작업이라고 제안합니다. 스크립트를 작성할 수도 있습니다.

저는 이 리포지토리에 기여한 사람이 아니므로 구현 방법에 대한 컨텍스트가 없습니다. 그 때문에 이것은 매우 순진한 것일 수 있지만 이것을 선택적 스위치로 구현하는 것은 가능하지 않을까요? 이것이 아무것도 깨지지 않도록?

이 전체 문제는 선택적 스위치를 구현할 수 있는 다양한 방법에 대해 논의하고 있습니다. 여러 가지 방법이 있습니다.

이것은 전적으로 자원 봉사자들로 구성된 오픈 소스 프로젝트입니다. 기능이 수락되면 팀이나 외부의 누군가가 기능을 선택하여 수행할 때까지 기다립니다. 누구에게나 작업을 할당하는 "보스"는 없습니다. 실제로 그것을 완료하는 데 전념할 시간이 없다면 아무도 그렇게 하지 않은 것은 좋은 일입니다. 그렇게 하면 능력과 관심이 있는 사람이라면 누구나 사용할 수 있습니다.

PR은 항상 환영하지만 NUnit의 다른 많은 것들을 깨뜨릴 가능성이 있기 때문에 누군가에게 이것은 아마도 처음 기여가 아닐 것입니다. 어쨌든 내 의견.

나는 더 이상 과거처럼 적극적으로 기여하지 않고 있습니다. 그래서 내가 어떻게 해야 하는지에 대한 내 의견은 그것을 선택하는 사람을 위한 조언으로 주어졌습니다.

나는 그것이 잠시 동안 주변에 있었다는 데 동의하며 직접 수행하는 것을 보고 싶습니다.

@BlythMeister 제 생각에는 스위치가 그것을 조금 지나치게 단순화한다고 생각합니다. 아시다시피 다른 사람들은 그렇지 않을 수도 있습니다.

물론 스위치지만 전구만 켜는 것이 아닙니다. 라디오를 AM에서 FM으로 전환하는 것과 비슷합니다. 완전히 새로운 회로가 작동합니다.

이 경우 관련된 것은 테스트 실행에서 완전히 새로운 수명 주기이므로 상당한 양의 코드를 교체해야 합니다. 작은 일이 아닙니다. 위험은 새로운 "회로"가 어떤 식으로든 기존 회로에 영향을 미치지 않도록 하는 데 있습니다.

죄송합니다. "스위치"가 간단하지 않은 이유에 대한 설명이 모호했습니다!

@BlythMeister 저는 실제로 Selenium 테스트 장치를 구동하기 위해 테스트 중에 상태를 추적한 다음 테스트가 완료된 후 폐기하기 위해 일회용 개체를 생성하여 설명한 대로 정확하게 수행했습니다. 그 접근 방식의 한 가지 주요 문제는 국가가 해체를 지속하지 않는다는 것입니다. 결과적으로 테스트 상태가 테스트 메서드 자체 내에서 확인되지 않고 분해 중에만 평가될 수 있기 때문에 실패한 테스트(스크린샷, 로그 또는 기타 상태 조각 캡처)에 대해 조건부로 작업을 실행할 수 없습니다. 따라서 상태 개체는 테스트를 스레드로부터 안전하게 만드는 강력한 방법이지만 분해하는 동안 테스트 결과로 작업을 수행할 필요가 없는 경우에만 작동합니다.

테스트 결과로 작업을 수행하는 것은 TearDown이 설계한 것이 아니라는 점을 염두에 두는 것이 좋습니다. 물론 많은 사람들이 그런 식으로 사용한다는 것을 알고 동기를 이해하지만 본질적으로 TearDown이 테스트의 일부이고 끝날 때까지 끝난 것이 아니라는 사실로 귀결되는 까다로운 코너 케이스가 많이 있습니다.

NUnit 3를 통해 우리는 엔진 확장을 사용하여 프레임워크 외부에서 결과를 검사하는 더 많은 사용자를 보기를 희망했지만 테스트 자체 내에서 작업하는 것이 더 친숙하고 접근 가능한 것 같습니다.

@찰리풀

1. 모든 조명기 레벨 OneTimeSetUp 는 이제 여러 번 실행됩니다. 이렇게 하면 일회성 설정으로 인한 효율성 향상이 제거되고 경우에 따라 의미 체계가 변경될 수 있습니다. 특히 초기화가 어떤 방식으로(예: 데이터베이스 설정) 전역 상태에 영향을 미치는 경우 오류가 발생할 수 있습니다. 이것은 나에게 용납할 수 없는 파손처럼 보입니다.

테스트 사례당 인스턴스 기능을 구현할 수 없고 여전히 OneTimeSetUp을 한 번만 실행할 수 없는 이유는 무엇입니까(메인 스레드가 호출하는 것을 기억하도록 유지)?

인스턴스를 초기화한 기존 OneTimeSetUp이 손상되기 때문에 매우 일반적입니다.

나는 이것을 모든 스위치 기반 솔루션의 문제로 봅니다. 테스트 픽스처에 대한 완전히 새로운 대안을 정의하면 문제가 되지 않습니다. 이 접근 방식은 상당히 매력적입니다.

인스턴스를 초기화한 기존 OneTimeSetUp이 손상되기 때문에 매우 일반적입니다.

"테스트 사례당 인스턴스" 기능이 활성화된 경우 정적 OneTimeSetUp 및 OneTimeTearDown 메서드만 허용하는 것은 어떻습니까? 그렇게 하면 해당 메서드 내에서 초기화된 멤버가 정적으로 강제되므로 조명기 인스턴스 간에 분명히 공유됩니다.

이 Github 문제의 주요 동기는 병렬화이지만 _최소한의 놀라움의 원칙_과 _서로 영향을 미치는 테스트로 인한 오류 방지_도 동기로 제시하고 싶습니다. (이미 다른 분이 언급하셨다면 죄송합니다.)

이 다소 오래된 스레드에서 충분히 다시 읽지 않은 경우에 대비하여 내 의견은 기능에 대해 주장하는 것이 아니라 제안된 특정 구현에 대해 주장하는 것입니다. 나는 TestFixture를 다르게 작동하는 완전히 새로운 유형의 고정 장치로 교체하는 것을 선호합니다.

나는 여기서 내가 최소의 놀라움의 교장을 잘 한다고 생각한다. 새 고정 장치가 다르게 작동하는 것은 놀라운 일이 아닙니다.

반면에 기존 조명기를 제어하는 ​​플래그를 생성하면 현재 구현에서 해당 플래그에서 분기해야 하는 5개 또는 6개의 다른 위치를 생각할 수 있습니다.

그렇다고 두 조명기 유형이 특정 코드를 공유하지 않을 수 있다는 말은 아닙니다. 그러나 그것은 사용자의 관점 밖일 것입니다.

@fschmied BTW, 우리가 새로운 프레임워크(또는 NUnit 4)를 만들고 있다면 나는 다르게 주장할 것입니다... NUnit 2와 3에서 테스트가 서로 간섭하는 것을 훨씬 더 어렵게 만들었어야 한다고 생각합니다. 그러나 , NUnit 3에서 변경하는 한 호환성 규칙을 생각합니다.

나는 TestFixture를 다르게 작동하는 완전히 새로운 유형의 고정 장치로 교체하는 것을 선호합니다.
[...]
나는 여기서 내가 최소의 놀라움의 교장을 잘 한다고 생각한다. 새 고정 장치가 다르게 작동하는 것은 놀라운 일이 아닙니다.

당신 말이 맞아요. 내가 의미하는 바는 원래 종류의 테스트 픽스처의 경우 동작이 여전히 대부분의 사람들에게 놀라울 것이라는 것입니다. (2주 전에 동료가 다른 테스트에 영향을 주는 테스트 사례를 발견하고 놀랐습니다. 그는 2013년부터 NUnit을 사용하고 있었기 때문에 이 문제를 찾아봤습니다.)

그러나 물론 하위 호환성, 구현 복잡성 및 원죄를 수정하려는 바람 사이의 절충점입니다[1].

OneTimeSetUp 문제로 돌아가서 : 테스트 픽스처 클래스가 테스트별로 인스턴스화되더라도 테스트 픽스처당 OneTimeSetUp 를 갖는 것이 여전히 중요하다고 생각합니다. OneTimeSetUp 가 인스턴스 상태를 조작하는 경우 혼란을 피하기 위해 OneTimeSetUp (및 OneTimeTearDown )를 테스트당 인스턴스 기능과 함께 정적으로 적용할 것을 제안합니다. (스위치로 구현하든 새로운 종류의 테스트 픽스처로 구현하든 상관없습니다.)

[1] 제임스 뉴커크 는 이렇게 썼다 .

NUnit V2.0을 작성할 때 가장 큰 문제 중 하나는 포함된 각 테스트 메서드에 대해 테스트 픽스처 클래스의 새 인스턴스를 만들지 않은 것입니다. 나는 "우리"라고 말하지만 이것은 내 잘못이라고 생각합니다. 각 테스트 방법에 대한 테스트 픽스처의 새 인스턴스를 생성하기 위한 JUnit의 추론을 잘 이해하지 못했습니다.

그는 또한 다음과 같이 씁니다.

[...] 지금 NUnit이 작동하는 방식을 변경하는 것은 어려울 것입니다. 너무 많은 사람들이 불평할 것입니다 [...]

:)

예, Jim과 저는 이 문제에 대해 수년간 논쟁을 벌였습니다. :smile: 우리가 동의하는 한 가지는 마지막 문장입니다. Jim은 선호하는 접근 방식을 구현하기 전에 새로운 프레임워크를 수행했습니다. 나는 기본적으로 같은 일을 하고 있고 SetUp/TearDown은 내가 다르게 할 가능성이 높은 것 중 하나입니다.

꽤 많은 경험을 가진 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 당신은 너무 많습니다. 피드백과 도움을 주셔서 감사합니다.

나는 물건이 어떻게 만들어지는지 알고 있다고 생각합니다 / 무엇을 하는지 등등 천천히 그러나 확실하게

여기 LifeCycle 열거형에 대한 제 제안이 있습니다(또한 귀하의 제안으로 제 브랜치를 업데이트했습니다)

    /// <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의 현재 기본 모델이 당신을 물어뜯을 것이기 때문에 병렬 시나리오에서만 사용하는 유스 케이스를 이해합니다. 처음부터 이랬어

SingleInsance/InstancePerTestCase에 남겨두어야 할 수도 있습니다.

또 다른 질문은 여기에서 IDisposable 패턴을 처리해야 한다는 것입니다. 그러면 SetUp/TearDown이 거의 중복되지만 XUnit 스타일로 훨씬 더 자연스럽게 느껴질 것입니다.

우리는 이미 IDisposable을 구현하는 모든 테스트 설비를 처분합니다. 계속 작동하는지 확인하기만 하면 됩니다.

좋아, 할 것이다.

아마도 오늘 테스트 케이스를 추가하기 시작할 것입니다. 그러나 이러한 핵심 메커니즘 때문에 InstancePerTestCase가 켜져 있을 때 동일한 작업이 작동하는지 확인하는 꽤 많은 케이스를 추가할 수 있습니다. 잘못된 경우 수정해 주세요.

DisposeFixtureCommand는 Dispose 호출을 처리합니다.

IMO의 주요 문제는 테스트 픽스처에 대한 전체 명령 스트림이 __각 테스트__에 대해 호출되도록 하는 것입니다. 지금까지 내가 본 변경 사항은 작업을 수행하는 것처럼 보이는 명령 스트림을 올바르게 생성하지만 핵심 질문은 각 테스트 사례에 대해 호출되도록 하는 방법입니다. (픽스처의 명령 구조는 테스트 케이스의 구조와 다릅니다.) 나는 복합 작업 항목이 컨텍스트에 민감해야 하고 명령을 올바르게 호출해야 한다고 생각하지만(당신이 한 것처럼) 기회를 얻을 수 있을지 확신할 수 없습니다. __every__ 테스트 케이스에 대해 그렇게 하기 위해. (나는 코드를 읽는 중이므로 틀릴 수 있습니다.)

@CharliePoole 은 당신이 맞는 것 같습니다. 테스트 방법을 정확히 실행하는 것에 대해 약간의 그래프를 작성했습니다.

현재 나는 RunChildren 루프에서 테스트 개체 인스턴스를 생성하지만 내가 놓친 다른 래퍼가 있는지/누군가 새 래퍼가 필요한지 여부는 말할 것도 없이 Retry/Repeat 명령에는 충분하지 않습니다.
TestMethodCommand에 훨씬 더 가까워야 합니다.

나는 최신 변경 사항을 업데이트했습니다.
https://github.com/avilv/nunit/tree/instance-per-test-2

제거된 InstancePerTestCaseWhenCasesAreParallel
CompositeWorkItem MakeOneTimeSetUpCommand 그것을 SimpleWorkItem MakeTestCommand 내부에 구축 / 폐기 조명기 추가, 생략을 통해 구현 FixtureLifeCycle

잘 작동하는 것 같으며 프레임워크가 구축되는 방식에 더 적합합니다.
이제 모든 것이 올바르게 작동하는지 확인하기 위해 많은 단위 테스트를 추가해야 합니다.

이것이 다음 버전 이전에 검토될 가능성이 있습니까? 물론 개선/변경을 위해 여전히 메신저

이 접근 방식은 나에게 좋은 소리이며 우리가 그렇게 할 수 있다면 다음 릴리스에서 사용하고 싶습니다!

우리가 이것을 검토할 수 있는 기회가 있습니까? 정말 가까워진 느낌

이 기능에 어떤 움직임이 있었는지 궁금하십니까? @avilv 가 꽤 근접한 것 같습니다. 이와 같은 기능을 오랫동안 기대해 왔으며 사용하게 되어 기쁩니다!

모두 감사합니다!

이 기능이 지금 작동합니까?

@CharliePoole @avilv 최신 버전을 검토해

@janissimson 죄송합니다. 하지만 저는 더 이상 이 프로젝트에 참여하지 않으므로 제 리뷰에서 진행되지 않습니다. @nunit-framework-team 누군가가 이것을 검토 할 수 없습니까?

#3427을 병합하기 위해 수행한 모든 작업에 감사드립니다. @rprouse 릴리스에서 이를 언제 예상할 수 있는지 알 수 있습니까?

새로운 기능을 어떻게 사용합니까? 누군가가 새로운 속성과 이를 적절하게 사용하는 방법에 대한 간단한 설명을 작성할 수 있습니까?

앞으로 몇 주 안에 출시할 계획입니다. 까지 기다리고 싶었습니다. NET 5는 최종 버전이며 릴리스 전에 약간의 최종 테스트를 수행합니다. 문제가 없을지 의문이지만 너무 가깝기 때문에 기다리는 것이 낫지 않을까 생각했습니다.

@rprouse 언제 새 버전을 출시할 예정이신가요? 이 기능을 사용하고 싶습니다.

@janissimsons 곧. 우리는 .NET 5.0 빌드와 몇 가지 다른 문제와 관련된 몇 가지 문제를 해결한 다음 릴리스하겠습니다. 이 프로젝트 보드에서 상태를 추적할 수 있습니다. https://github.com/nunit/nunit/projects/4

이것은 멋진 소식입니다!

이것이 NUnit에서 다음을 가능하게 한다는 것을 올바르게 이해하고 있습니까?

다음을 모두 결합합니다.

• 테스트가 매개변수화됨
• 테스트를 병렬로 실행합니다.
• 동일한 테스트의 매개변수화된 변형을 병렬로 실행할 수 있습니다.
• 테스트는 데이터 기반 가능

https://github.com/jawn/dotnet-parallel-parameterized-tests 에서 과거에 몇 가지를 시도했습니다.

새 릴리스는 여전히 .NET Full Framework 4.7.2 또는 최소 4.8과 호환됩니까?

친애하는,
박사

@jawn 나는 모든 것이 효과가 있을 것이라고 믿습니다. 그렇습니다. 나는 그 모든 것을 테스트했지만 NUnit에는 많은 기능이 있으므로 일부 기능 조합이 있는 경우가 있을 수 있습니다. 야간 NuGet 패키지를 자유롭게 가져와 테스트해 보세요! 출시하기 전에 더 많은 테스트와 피드백을 원합니다.

@drauch 예, 3.13 릴리스는 여전히 .NET 3.5를 지원합니다.

@avilv 수고하셨습니다 !!
그런데 어떤 도구를 사용하여 그 멋진 흐름도를 만드셨습니까?
감사 해요

@rprouse 이 새로운 기능을 사용하는 방법에 대한 문서를 업데이트해 주시겠습니까? 감사 해요!

@janissimsons 릴리스용 문서를 업데이트할 계획입니다. 짧은 버전은 [FixtureLifeCycle(LifeCycle.InstancePerTestCase)] 를 테스트 클래스에 추가하는 것입니다. 아마도 [Parallelizable(ParallelScope.All)] 와 함께 테스트 클래스의 인스턴스가 클래스 내에서 실행되는 각 테스트에 대해 인스턴스화될 것입니다. 이렇게 하면 변수를 변경하는 다른 테스트에 대해 걱정하지 않고 병렬 테스트 실행에서 클래스의 멤버 변수를 사용할 수 있습니다.

@LirazShay 스크린샷의 다이어그램은 Visual Studio Enterprise에서 생성되었습니다. 예를 들어 솔루션 탐색기에서 선택 항목을 마우스 오른쪽 버튼으로 클릭하고 "코드 맵에 표시"를 선택할 수 있습니다. https://docs.microsoft.com/en-us/visualstudio/modeling/map-dependencies-across-your-solutions ReSharper에도 유사한 기능이 있습니다.

@jnm2 감사합니다!!!
나는 VS 엔터프라이즈를 가지고 있으며 매우 도움이 될 수 있는 이 기능에 대해 알지 못했습니다.
팁 너무 감사합니다

이것이 릴리스되었으며 3.13 릴리스의 일부라는 것이 맞습니까?

이것이 릴리스되었으며 3.13 릴리스의 일부라는 것이 맞습니까?

특히 #3720의 어셈블리 수준 속성 적용과 관련하여 몇 가지 문제가 관찰 및 수정되었다고 생각하며 현재 3.13.1을 기다리고 있습니다.

NUnit 3.13.1이 출시되었습니다.
더 이상 문제가 남아 있습니까?

아니 그것이 폐쇄 된 이유입니다 @andrewlaser