Autofixture: NCrunch 및 AutoFixture 통합 문제

안녕하세요 엔크런치 개발자입니다.

이 문제에 대한 해결책을 찾기 위해 기꺼이 협력하겠습니다. 현재 디자인에서는 슬프게도 통합 지점 측면에서만 문제를 해결할 수 있는 옵션이 없습니다. 현재 디자인에서 문제를 경험한 사람은 주자가 유일한 사람이 아닐 것이라고 생각합니다.

내가 작성한 다양한 문서 및 지원 포럼 게시물을 통해 이해하셨겠지만 문제의 근원은 AutoFixture의 테스트 매개변수 무작위 생성에 있습니다. 테스트 매개변수는 테스트를 식별하고 후속적으로 수행하는 데 있어 중요한 요소이기 때문에 테스트가 구성/발견될 때마다 매개변수가 변경되면 테스트의 선택적 실행이 불가능합니다.

이 문제를 해결하기 위해 내가 생각할 수 있는 유일한 신뢰할 수 있는 방법은 테스트 매개변수의 모든 무작위 생성을 제거하고 대신 고정 값(예: 자리 표시자 또는 const)을 사용하거나 매개변수 값의 시드를 테스트 케이스 자체로 제한하는 것입니다. 이런 식으로 테스트는 항상 정확히 동일하며 다른 테스트와 동일하게 일관되게 찾을 수 있습니다. 매개변수 생성을 위해 AutoFixture를 사용한 모든 사용자는 테스트 목적으로 '관심하지 않는' 매개변수에 대해 그렇게 했기 때문에 이 접근 방식이 사용자의 눈에 실제적인 단점이 없기를 바랍니다. . 이것의 이점은 NCrunch의 모든 버전에서 즉시 작동하고 NCrunch 또는 다른 러너에 대한 코드 변경이 필요하지 않다는 것입니다.

@remcomulder 여기에 참여해주셔서 대단히 감사합니다. 대단히 감사합니다! 나는 그것을 조금 조사했고 내 발견을 공유하고 싶습니다. 내 모든 결과는 xUnit에만 적용

TL DR: xUnit은 이러한 이론을 지원하고 NCrunch는 xUnit에서도 이를 지원해야 합니다. NUnit의 경우 - 이는 공개 질문이며 아직 조사하지 않았습니다.

우리가 사용하는 기능은 xUnit에 대해 _합법적인_ 것 같습니다. (임의의 데이터를 생성하기 때문에) 이론을 미리 발견할 수 없음을 나타내는 자체 TestDataDiscoverer 가 있습니다. 나중에 이 발견 자로 AutoDataAttribute 를 장식합니다. xUnit 은 이 속성을 존중 하며 검색 중에 매개변수 값을 확인하지 않습니다.

현재 디자인에서 문제를 경험한 사람은 주자가 유일한 사람이 아닐 것이라고 생각합니다.

사실, 그것은 사실이 아니며 R#과 VS는 모두 그러한 이론에서 잘 작동합니다. 또한 자동 생성 데이터가 포함된 경우에도 특정 이론을 다시 실행할 수 있습니다. 검색 및 실행 단계도 포함하고 오픈 소스이므로 VS에 집중하는 것이 좋습니다.

다음 테스트 코드를 고려하십시오.

using Ploeh.AutoFixture.Xunit2;
using Xunit;

namespace Playground
{
    public class UnitTest
    {
        [Fact]
        public void StableTest()
        {
            Assert.True(true);
        }

        [Theory]
        [InlineData(1)]
        public void StableInlineTest(int value)
        {
            Assert.Equal(1, value);
        }

        [Theory, AutoData]
        public void VolatileTest(int value)
        {
            Assert.True(value % 2 == 0);
        }

        [Theory]
        [InlineAutoData(10)]
        [InlineAutoData(20)]
        [InlineAutoData(30)]
        public void VolatileTestWithInline(int value, int autoValue)
        {
            Assert.NotEqual(value, 40);
        }
    }
}

.NET Framework 테스트 라이브러리 프로젝트. VS 2017.3. 대상 프레임워크: 4.5.2. 설치된 패키지:

• xunit 2.2.0
• xunit.runner.visualstudio 2.2.0
• AutoFixture 3.50.6
• AutoFixture.Xunit2 3.50.6

VS에서 검색을 트리거하면 다음 출력이 표시됩니다.

알 수 있듯이 데이터 검색을 지원하는 이론( StableInlineTest )의 경우 VS runner는 테스트가 실행될 실제 데이터를 보여줍니다( 1 ). 데이터 검색을 지원하지 않고 자동 생성된 데이터( VolatileTest , VolatileTestWithInline )를 포함하는 테스트의 경우 VS는 이론 사례를 발견하지 않고 전체 이론만 보여줍니다. 실행한 후에만 이 특정 호출에 대한 값을 볼 수 있습니다.

이제 특정 이론을 다시 실행할 수 있으며 _모든 이론 사례_를 다시 실행할 것입니다.

보시다시피 실제로 이러한 이론을 지원하는 방법이 있으며 xUnit은 이를 완벽하게 수행합니다. NCrunch는 일부 이론 사례를 미리 발견할 수 없다는 사실을 고려해야 합니다. 이러한 이론의 경우 특정 사례가 아니라 전체 이론을 다시 실행해야 합니다. 나는 그것이 가능하지 않은 이유를 알 수 없습니다.

이 문제를 해결하기 위해 내가 생각할 수 있는 유일한 신뢰할 수 있는 방법은 테스트 매개변수의 모든 무작위 생성을 제거하고 대신 고정 값(예: 자리 표시자 또는 const)을 사용하는 것입니다.

현재 xUnit은 표시 이름을 변경하고 생성된 데이터를 자리 표시자로 바꾸는 API를 노출하지 않습니다. 나는 그들을 위해 문제를 만들었습니다( 여기 참조). 그러나 Brad의 대답은 그것이 비현실적이며 우리가 이미 하고 있는 발견을 단순히 비활성화할 것을 제안한다는 것입니다.

또는 매개변수 값의 시딩을 테스트 케이스 자체로 제한합니다.

불행히도 현재 우리 제품에서는 불가능하며 단일 시드를 지원하기 위해 많은 항목을 다시 작성해야 합니다.

회원 데이터

여기 문서에는 다른 샘플이 있습니다(XUnit으로 다시 작성했습니다).

public class MemberDataSample
{
    public IEnumerable<object[]> GetData()
    {
        yield return new object[]
        {
            DateTime.Now
        };
    }

    [Theory, MemberData(nameof(GetData), DisableDiscoveryEnumeration = true)]
    public void DateTheory(DateTime dt)
    {
        Assert.True(DateTime.Now - dt < TimeSpan.FromMinutes(1));
    }
}

DisableDiscoveryEnumeration 속성이 있으므로 xUnit에 대해 절대적으로 합법적입니다. 위의 샘플처럼 작동합니다. 이론 사례는 미리 발견되지 않습니다.

결론

xUnit은 테스트가 휘발성인지 여부를 이해하는 도구를 제공하는 것 같습니다(사전 검색 열거 지원을 통해). VS 구현을 샘플로 사용하여 이를 처리하고 제품에서 동일한 작업을 수행하는 방법을 이해할 수 있습니다. 아마도 그들은 단순히 xUnit SDK와 메시지 싱크를 사용합니다.

R#과 VS 모두 이러한 훌륭한 이론을 지원한다는 점을 감안할 때 실제로 모든 것이 우리 제품에 맞다고 생각하게 만듭니다..

NUnit에 관해서는 - 아직 조사하지 않았기 때문에 나중에 논의합시다. 아마도 그런 API가 없을 것입니다.

내가 찾은 결과를 감안할 때 xUnit 지원에 대한 의견을 공유해 주시겠습니까? 에 대한 지원을 추가하시겠습니까?
xUnit(모든 테스트 재실행 중지) 및 중지하여 비호환성 경고를 표시하시겠습니까? 😉

여기서 사과해야 할 것 같습니다. 위에서 설명한 사용 사례는 설명한 이유로 NCrunch에서 올바르게 작동합니다. Xunit은 이론의 사전 열거를 피하고 안전하게 식별되고 실행되는 단일 테스트로 축소하고 있습니다. 지금 이것을 테스트하면 NCrunch가 올바르게 수행하는지 확인할 수 있습니다. InlineAutoData에는 명백한 문제가 없는 것 같습니다.

왜 이것이 더 일찍 실패했는지 잘 모르겠습니다. 나는 현재 스스로 실패하는 시나리오를 만들 수 없습니다. 사용자가 InlineAutoData가 작동하지 않는다고 언급한 것을 알고 있습니다. 하지만 사용자가 앞으로 나와 이러한 경우에 대한 예를 제공해야 할 것 같습니다.

NCrunch와 VS Runner를 모두 깨뜨릴 것으로 알고 있는 특정 사용 사례에 주의를 기울이고 싶습니다. ReSharper 및 TD.NET도 손상될 것이라고 가정하지만 설치하지 않았기 때문에 테스트하지는 않았습니다.

using Ploeh.AutoFixture;
using Ploeh.AutoFixture.Xunit2;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Xunit;

namespace XUnitAutoFixture
{
    public class TestFixture
    {
        private static readonly Fixture Fixture = new Fixture();

        public static IEnumerable<object[]> SomeTestData()
        {
            yield return new object[] { Fixture.Create<string>() };
            yield return new object[] { Fixture.Create<string>() };
        }

        [Theory, MemberData(nameof(SomeTestData))]
        public void Test(object value)
        {

        }
    }
}

위의 코드는 모든 선택적 실행 시나리오에서 실패합니다. 그러나 동일한 단계에서 테스트가 발견되고 실행되면 통과합니다. 이 시나리오는 사용자가 이 작업을 수행하고 지원을 요청함에 따라 NCrunch가 AutoFixture에 대해 제공한 경고의 촉매제였습니다. AutoFixture가 사전 열거를 비활성화하는 것에 대해 알지 못했기 때문에 InlineAutoData가 동일하다고 (잘못) 가정했습니다.

내 현재 가정은 당신이 그러한 시나리오를 지원하지 않는다는 것입니다. 이 올바른지?

지금 이것을 테스트하면 NCrunch가 올바르게 수행하는지 확인할 수 있습니다.

대단해! 실제로 xUnit이 NCrunch에서 완벽하게 지원된다는 소식을 듣게 되어 기쁩니다 🎉 NUnit은 항상 서툴렀고 여기서 무엇을 할 수 있는지 조사해야 합니다.

그러나 여전히 NCrunch 및 AutoFixture의 문제를 관찰합니다. 현재 AutoFixture가 포함된 xUnit 프로젝트가 있으며 한 줄이라도 변경하면 모든 테스트가 다시 실행됩니다. 누락된 항목이 없는지 확인하기 위해 AutoFixture를 감지할 때 이러한 동작을 활성화하는 것 같습니다.

그렇습니까? 그렇다면 xUnit에서 모든 것이 정상이므로 해당 동작을 비활성화하도록 수정해 주시겠습니까?

NCrunch와 VS Runner를 모두 깨뜨릴 것으로 알고 있는 특정 사용 사례에 주의를 기울이고 싶습니다.
내 현재 가정은 당신이 그러한 시나리오를 지원하지 않는다는 것입니다. 이 올바른지?

예, 그 시나리오는 모든 주자를 깨뜨릴 것입니다. 그러나 포럼의 어딘가에서 올바르게 지적되었으므로 AutoFixture 때문이 아닙니다. 다음과 같이 작성해도 작동하지 않을 수 있기 때문입니다.

public class TestFixture
{
    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { DateTime.Now.Ticks };
        yield return new object[] { DateTime.Now.Ticks };
    }

    [Theory, MemberData(nameof(SomeTestData))]
    public void Test(object value)
    {

    }
}

이러한 시나리오의 경우 사전 검색을 수동으로 비활성화하여 다음과 같이 표시되도록 하는 것은 사용자의 책임입니다( DisableDiscoveryEnumeration 속성에 주의).

public class TestFixture
{
    private static readonly Fixture Fixture = new Fixture();

    public static IEnumerable<object[]> SomeTestData()
    {
        yield return new object[] { Fixture.Create<string>() };
        yield return new object[] { Fixture.Create<string>() };
    }

    [Theory, MemberData(nameof(SomeTestData), DisableDiscoveryEnumeration = true)]
    public void Test(object value)
    {

    }
}

실제로 데이터 생성을 위한 AutoData 및 InlineAutoData 속성이 있으므로 매우 드문 시나리오라고 가정합니다. 또한 AutoFixture는 단순한 도구이며 올바르게 사용하는 것은 개발자의 책임입니다.

도구를 잘못 사용할 수 있는 사람들이 있다고 해서 엔크런치를 특수 모드로 옮기지는 않을 것입니다. 여기에서 우리가 할 수 있는 최선은 알려진 문제를 어딘가에 넣어 이 특정 시나리오를 설명하고 사람들에게 xUnit을 적절하게 사용하도록 요청하는 것입니다(이에 대해 모를 수 있음).

AutoFixture를 감지하는 경우 특별한 방법으로 테스트를 실행하는지 확인해 주시겠습니까? 그렇다면 xUnit에 대해 해당 모드를 비활성화할 수 있습니까(NUnit의 경우 그대로 유지하는 것이 좋습니다). 또한 이 페이지도 업데이트되어야 합니다.

현재 NCrunch는 호환성 경고 외에 AutoFixture에 대한 특별한 처리를 구현하지 않습니다. 경험한 동작은 아마도 선택한 엔진 모드 때문일 것입니다. 완전히 구성 가능합니다. '영향을 받는 테스트를 자동으로 실행하고 다른 테스트를 수동으로 실행' 모드로 전환하면 엔진이 예상대로 작동하는 것을 볼 수 있을 것입니다.

당신에게서 배운 것을 바탕으로 NCrunch에서 AutoFixture 경고를 완전히 제거할 준비가 되었습니다. 나는 경고가 너무 광범위하고 AutoFixture의 일부 기능이 여전히 올바르게 작동하고 있다는 것이 매우 초기에 명확해 졌기 때문에 사용자가 그것을 다시 말하도록 이미 확신했습니다. AutoFixture가 xunit에서 구현되는 방식을 심각하게 잘못 이해한 것 같습니다.

그래서 이것이 우리에게 가장 좋은 시나리오라고 생각합니다. 나를 가장 심하게 망가뜨린 사용 사례는 어쨌든 기술적으로 지원되지 않으며 다른 모든 것은 잘 작동합니다. 한편, 지나친 호환성 경고에 대해 저를 용서할 이유를 찾으신다면, 이것을 잘못된 결론으로 ​​테스트하고 검증한 제 부끄러움을 잊도록 노력하겠습니다.

한편, 지나친 호환성 경고에 대해 저를 용서할 이유를 찾으신다면, 이것을 잘못된 결론으로 ​​테스트하고 검증한 제 부끄러움을 잊도록 노력하겠습니다.

걱정 마! 정말 괜찮습니다. 그리고 우리 모두는 서로의 이해를 돕기 위해 여기 있습니다 😅 티켓을 확인하고 이에 대해 논의해 주셔서 감사합니다. 너무 많습니다 🥇

당신에게서 배운 것을 바탕으로 NCrunch에서 AutoFixture 경고를 완전히 제거할 준비가 되었습니다.

글쎄요, 우리는 여전히 NUnit에 문제가 있습니다(우리는 진행 중 입니다 ). 그래서 이 메시지는 NUnit 프로젝트와 관련이 있는 것 같습니다. NUnit에 대한 전체 지원(또는 최소한 해당 지원을 활성화하는 방법)을 도입하지 않는 한 xUnit에 대해서만 비활성화하는 것이 좋습니다.

나에게는 아직 한 가지 명확하지 않은 것이 있습니다. AutoFixture & NUnit 등을 지원하지 않는다는 것은 무엇을 의미합니까? 네, 테스트 이름은 매번 다르지만 모든 테스트를 다시 실행해도 상관없나요(엔진 모드가 그렇게 설정되어 있는 경우)? 아니면 "영향을 받은 전용" 엔진을 더 이상 지원하지 않는다는 의미입니까? 내 생각은 No support 라고 말하는 대신 우리가 지원하지 않는 특정 시나리오로 범위를 좁히는 것이 더 나을 것이고 나머지 시나리오는 괜찮을 것입니다.

'영향을 받는 테스트를 자동으로 실행하고 다른 테스트는 수동으로 실행'

3.10.0.20 설치에서 이 설정을 찾을 수 없습니다. 당신은 의미합니까 Only consider tests 'Out of date' if they are 'Impacted' 그로 설정해야 설정이 true ? 어디선가 놓쳤다면 죄송합니다 - 저는 이 제품이 조금 생소합니다..

문서 업데이트

이 페이지에서 xUnit 및 AutoFixture의 경우를 _제거_하지 않고 대신 올바르게 사용하는 방법을 설명하는 것이 합리적일 것입니다( DisableDiscoveryEnumeration 속성 사용). 또한 xUnit에 대한 "NUnit Test Case With Inconsistent Name" 샘플을 설명하고 DisableDiscoveryEnumeration 속성을 MemberDataAttribute 와 함께 사용하도록 요청하는 것이 좋습니다.

나에게는 아직 한 가지 명확하지 않은 것이 있습니다. AutoFixture & NUnit 등을 지원하지 않는다는 것은 무엇을 의미합니까? 네, 테스트 이름은 매번 다르지만 모든 테스트를 다시 실행해도 상관없나요(엔진 모드가 그렇게 설정되어 있는 경우)? 아니면 "영향을 받은 전용" 엔진을 더 이상 지원하지 않는다는 의미입니까? 내 생각은 지원 안 함이라고 말하는 대신 지원하지 않는 특정 시나리오로 범위를 좁히는 것이 더 나을 것이고 나머지 시나리오는 괜찮을 것입니다.

이것은 NCrunch에서 테스트의 수명 때문입니다. NCrunch는 모든 테스트(합격/불합격 결과, 코드 커버리지 데이터, 성능 데이터, 트레이스 출력 등)에 할당되는 중요한 상태를 가지고 있습니다. 이 데이터는 VS 세션 간에도 테스트 프레임워크가 테스트를 계속 '발견'하는 한 지속됩니다. 테스트 프레임워크가 동일한 식별자를 가진 테스트가 없다고 보고하면 테스트가 사라진 것으로 간주되고 모든 상태가 소멸됩니다.

불안정한 매개변수를 사용하여 테스트를 생성할 때 테스트를 검색하기 위해 테스트 프레임워크를 호출할 때마다 테스트의 식별자가 변경되었기 때문에 완전히 새로운 테스트가 생성됩니다. 그 결과 NCrunch가 NUnit을 호출하여 테스트를 검색할 때마다(테스트 프로젝트의 모든 빌드 후에 일관되게) 매개변수가 불안정한 테스트에 대해 유지된 모든 상태가 삭제됩니다. 좋지 않은 일입니다. 즉, 충격 감지가 작동하지 않고 엔진이 테스트를 재실행하고 일시적인 결과를 넘기는 수많은 추가 작업을 수행합니다.

그러나 문제는 더 깊어집니다. 테스트 상태의 덤핑이 유일한 실제 문제인 경우 불안정한 테스트에 대한 처리는 여전히 엔진에 의해 실행되고 결과가 보고된다는 점에서 여전히 '작동'할 수 있습니다. 더 깊은 문제는 NCrunch의 병렬화, 선택적 실행 및 분산 처리에서 비롯됩니다.

병렬 실행을 수행하려면 NCrunch가 테스트를 병렬로 실행하는 여러 테스트 프로세스를 사용해야 합니다. NUnit의 역학은 테스트가 실행되기 전에 먼저 발견되어야 하는 것과 같습니다. 즉, 실행에 사용되는 각 프로세스 내에서 실행되는 완전히 별도의 검색 단계가 있어야 하므로 두 개의 프로세스가 있는 경우 테스트를 두 번 검색해야 합니다. 테스트에 불안정한 매개변수가 있는 경우 각 프로세스에는 완전히 다른 테스트 세트가 있으므로 엔진이 실행을 위해 프로세스 간에 테스트의 전체 마스터 목록을 분할할 수 없습니다. 이 문제는 원격 실행 프로세스가 완전히 다른 환경의 다른 하드웨어에서 실행되기 때문에 분산 처리를 사용할 때도 확장됩니다.

선택적 실행의 문제도 있습니다. NCrunch의 기본 작동 모드는 특별히 테스트를 실행하라는 지시가 있을 때 항상 새로운 테스트 프로세스를 생성하는 것입니다. 이것은 슬레이트를 지우고 다른 주자와 가능한 한 일관성을 유지하기 위한 것입니다. 이러한 기능은 불안정한 매개변수에서는 작동하지 않습니다. 새 테스트 프로세스를 생성하려면 테스트를 재발견해야 하며, 이는 매개변수가 변경된 경우 후속적으로 식별할 수 없기 때문입니다.

NUnit에는 프로세스 간에 불안정한 매개변수가 있는 테스트를 식별하는 데 사용할 수 있는 자체 내부 ID 시스템이 있지만 이 ID 시스템은 테스트 생성 순서(즉, 증분식)를 기반으로 합니다. 이러한 시스템은 여러 버전의 테스트 어셈블리에서 테스트 상태를 관리해야 하는 테스트 실행자가 사용할 수 없습니다. 사용자가 새 테스트를 생성하면 모든 ID가 순서를 벗어나고 데이터가 위험할 정도로 오도되기 때문입니다. . NUnit 개발자는 이 시퀀스 기반 시스템에서 벗어나 테스트 속성 자체에서 생성된 ID로 이동하는 데 관심을 표명했습니다. 이는 Xunit이 수행하는 방식과 유사하며 불안정한 매개변수에서는 작동하지 않을 가능성이 높습니다.

나는 여전히 이러한 문제를 해결하는 가장 좋은 방법은 불안정한 매개변수의 일관된 시드를 수행하는 것이라고 믿습니다. 테스트는 반복 가능하고 일관성이 있어야 한다는 개념이 항상 존재하는데, 이는 테스트가 모든 입력을 완전히 무작위화하는 경우 달성하기 어렵습니다. 실제로 실행을 위해 무작위로 시드된 데이터를 생성하는 테스트는 코드가 제공된 데이터에 따라 다르게 동작할 수 있으므로 생성될 때마다 완전히 새로운 테스트입니다.

내 3.10.0.20 설치에서 이 설정을 찾을 수 없습니다. true로 설정해야 하는 '영향을 받은' 설정인 경우에만 테스트가 '오래됨'으로 간주된다는 것을 의미합니까? 어디선가 놓쳤다면 죄송합니다 - 저는 이 제품이 조금 생소합니다..

NCrunch 메뉴로 이동하여 '엔진 모드 설정'을 선택하면 옵션이 표시됩니다. 거기에 없으면 훨씬 이전 버전의 NCrunch에서 실행한 솔루션을 사용 중이고 레거시 엔진 모드만 표시하고 있을 수 있습니다. 어딘가에서 새로운 솔루션을 생성하면 이 문제가 해결됩니다.

@remcomulder 와우! 이렇게 자세한 설명 감사합니다! 이제 실제로 AutoFixture & NUnit이 현재 지원되지 않고 있다고 말하는 것이 더 쉽다는 것을 알았습니다. 후드 아래에 몇 가지 거대한 문제가 있기 때문입니다 😅

나는 여전히 이러한 문제를 해결하는 가장 좋은 방법은 불안정한 매개변수의 일관된 시드를 수행하는 것이라고 믿습니다.

사실 이번 PR에서는 조금 다른 생각을 가지고 있습니다. 테스트 이름을 변경하여 안정적으로 만들고 싶습니다. 예를 들어 다음과 같은 테스트가 주어졌습니다.

    [Test, StableNameAutoData]
    public void Sample(int a, Data d1, DataWithToString d2, ISomeData d3)
    {
        Assert.IsTrue(true);
    }

테스트 이름은 다음과 같습니다.

NUnit3RunnerTest709.TestNameTester.Sample(auto<System.Int32>,auto<NUnit3RunnerTest709.Data>,auto<NUnit3RunnerTest709.DataWithToString>,auto<Castle.Proxies.ISomeDataProxy>)

이름은 각 검색/실행 중에 항상 동일하지만 실제 인수 값은 매번 다릅니다.

NUnit에 대한 깊은 지식을 감안할 때 이 접근 방식을 어떻게 평가하시겠습니까? 그것은 당신을 위해 작동합니까? 특정 인수 값에 묶이기 보다는 이론 이름을 사용하기를 기대합니다. 따라서 테스트 이름이 안정적이라면 지금 식별할 수 있으므로 문제가 없을 것입니다. 구현을 시작하기 전에 확인해 주시겠습니까? ☺️

테스트는 반복 가능하고 일관성이 있어야 한다는 개념이 항상 존재하는데, 이는 테스트가 모든 입력을 완전히 무작위화하는 경우 달성하기 어렵습니다.

아마도 언젠가는 테스트가 동일한 인수로 재생될 수 있도록 안정적인 시드를 지원할 것입니다. 그러나 현재는 그것과 꽤 거리가 있어 현실적이지 않습니다 😕 오히려 사용자의 주장이 나중에 이해할 수 있을 정도로 정확할 것으로 기대합니다. 입력이 일부 범위에서 무작위로 추출된 경우에도 테스트가 실패한 이유.

NUnit에 대한 깊은 지식을 감안할 때 이 접근 방식을 어떻게 평가하시겠습니까? 그것은 당신을 위해 작동합니까? 특정 인수 값에 묶이기 보다는 이론 이름을 사용하기를 기대합니다. 따라서 테스트 이름이 안정적이라면 지금 식별할 수 있으므로 문제가 없을 것입니다. 구현을 시작하기 전에 확인해 주시겠습니까? ☺️

불행히도 NUnit에 대한 내 지식은 깊지 않습니다. NCrunch는 기본적으로 NUnit이 반환하는 이름을 사용하고 이를 식별자를 생성하는 데 사용합니다. 따라서 이론적으로 솔루션이 테스트의 물리적 이름을 다음과 같이 변경/안정화하는 한 NUnit API에서 반환된 경우 여기에서 괜찮습니다.
적어도 NCrunch의 경우.

주의해야 할 점은 사용자가 동일한 서명으로 여러 테스트를 생성할 가능성이 있다는 것입니다. 이름의 매개변수가 원시 유형으로 제거되는 경우 훨씬 더 가능성이 높아집니다. 이러한 시나리오를 알고 있는 한 오류 또는 이를 방지하기 위해 코드를 작성할 수 있습니다.

@remcomulder 마지막으로 이 문제를 종료할 수 있도록 업데이트를 제공합니다.

위에서 논의한 바와 같이 xUnit 프레임워크는 기본적으로 지원됩니다. 그러나 NUnit의 경우 휘발성 이름이 있는 테스트를 지원하지 않기 때문에 문제가 명확하지 않았습니다.

우리는 최근에 PR을 병합하고 NUnit의 안정적인 이름에 대한 지원을 추가하는 새 버전의 AutoFixture( v3.51.0 )를 출시했습니다. 현재로서는 사용자 측에서 수동 조치가 필요하지만( 여기 참조) v4에서는 즉시 사용하도록 할 것입니다.

방금 테스트한 결과 위의 방법을 사용하면 NCrunch가 수정된 테스트만 실행할 수 있으며 이제 제대로 작동하는 것으로 보입니다. 귀하의 일부 조치가 필요한지 여부가 확실하지 않습니다(예: 어딘가에 문서화). 또한 새로운 기능을 테스트하고 지금 잘 작동하는지 알려주시면 휴식을 취할 수 있습니다 😄

@zvirja 이에 대해

사용자 지원에서 시간을 절약할 수 있다고 생각하지만 아이디어가 있습니다. 우리 모두가 소프트웨어에서 발견하는 한 가지 문제는 많은 사람들이 도구를 선택하기 전에 문서를 읽지 않는다는 것입니다. 이제 NUnit에서 고유한 이름 문제를 해결하는 방법에 대해 조언할 수 있다는 사실을 아는 것이 유용하지만, 가장 좋은 방법은 항상 문제를 스스로 해결하도록 만드는 것입니다.

기본적으로 AutoFixture는 VolatileNameTestMethodBuilder를 사용합니다. 나는 이것이 이전 버전과의 호환성을 위한 것임을 인정하며 이것이 합리적이라는 데 동의합니다. 그러나 환경 변수를 사용하여 이 기본값을 무시하도록 허용한다면 어떻게 될까요? AutoFixture가 VolatileNameTestMethodBuilder를 사용하도록 강제하는 환경 변수(예: 'AutoFixture.FixedTestNames'=='1')를 지정할 수 있다면 사용자가 아무것도 할 필요 없이 러너가 빌더를 미리 지정할 수 있습니다. 이것은 또한 여러 러너를 사용하는 사람들에게 보너스가 될 것입니다. 그들은 암묵적으로 각 러너에 대해 다른 빌더를 사용할 수 있고(노력 필요 없이) 두 가지 장점을 모두 얻을 수 있기 때문입니다.

어떻게 생각하나요?

나는 이 작업에 빠른 테스트를 했고 그것은 나에게 견고해 보인다.

굉장해! 🎉 이제 모든 것이 제대로 작동하므로 이 문제를 종료할 수 있음을 의미합니다. 테스트와 참여에 감사드립니다 🥇

어떻게 생각하나요?

훨씬 더 우수하고 간단한 솔루션을 찾은 것 같습니다. FixedNameTestMethodBuilder 를 다음 달 또는 두 달에 출시될 v4(차기 주요 릴리스)의 기본 전략으로 만들 것입니다. 적절한 PR 이 이미 승인 되었으므로 코드가 있을 것입니다. 따라서 우리는 기본적으로 잘 작동하고 누군가가 휘발성 테스트 이름이 필요한 경우 수동으로 선택하여 결과를 명확하게 이해합니다.

나중에 제안한 대로 할 수 있습니다. 환경 변수/AppConfig를 검사하는 전환 전략을 추가하지만 실제로 필요한 경우에만 그렇게 하는 것을 선호합니다.

훨씬 더 우수하고 간단한 솔루션을 찾은 것 같습니다. 다음 달 또는 두 달에 출시될 v4(차기 주요 릴리스)에서 FixedNameTestMethodBuilder를 기본 전략으로 만들 것입니다.

그것은 나를 위해 잘 작동합니다 :) 나는 행복합니다! 모든 노력에 감사드립니다.

멋지다 😉 답변과 콜라보해주셔서 다시한번 감사드립니다 👍

양측에서 더 이상 조치가 필요하지 않으므로 이 작업을 종료합니다.

@remcomulder @zvirja 이 토론(비슷한 문제를 이해하는 데 도움이 됨)과 여기에서 보여 주신 헌신이 정말 대단하다고 말하고 싶었습니다! 두 분의 훌륭한 제품에 감사드립니다.