Autofixture: 복잡한 제약 조건이 있는 객체 생성

라디오 침묵 죄송합니다. 우리는 살아 있고 곧 답장을 드리겠습니다. 요즘 제 주요 업무로 매우 바쁩니다. 또한 NSubstitute v4 릴리스를 작업하고 있으므로 시간이 매우 제한적입니다. :pensive: 질문이 어렵기 때문에 답변을 게시하기 전에 가능한 모든 방법에 대해 생각하고 싶습니다.

기다려 주셔서 감사합니다. 계속 지켜봐 주세요 :wink:

안녕하세요,
그것에 대한 소식이 있습니까?
압력이 없습니다(나는 드릴 😄 을 알고 있고 실제로 차단하지도 않습니다. 교육받은 조언을 받고 싶습니다). 단지 가시성이 있는지 알아보기 위한 것입니다.
정말 감사합니다!

안녕하세요! 마지막으로 답변을 위해 약간의 유형을 할당했습니다. 답변이 너무 늦어서 죄송합니다 😊

우선 AutoFixture의 핵심은 매우 간단하며 제약 조건이 있는 복잡한 트리에 대한 기본 제공 지원이 없다는 점에 유의하십시오. 간단히 말해서 생성 전략은 다음과 같습니다.

• 공용 생성자 또는 정적 팩토리 메소드(현재 유형의 인스턴스를 리턴하는 정적 메소드)를 찾으십시오.
• 생성자 인수를 해결하고 인스턴스를 활성화합니다.
• 쓰기 가능한 공용 속성과 필드를 생성된 값으로 채웁니다.

현재 접근 방식을 사용하면 이전에 발견한 것처럼 종속성 제약 조건을 어떻게든 제어할 수 없습니다.

특정 유형을 빌드하는 방법을 지정하기 위한 몇 가지 사용자 지정 지점이 있지만 상대적으로 간단하고 복잡한 규칙을 지원하지 않습니다.

AutoFixture에서 이러한 종류의 구조 인스턴스를 생성하는 가장 좋은 방법은 무엇입니까? 내 말은, 나는 분명히 사용자 정의를 작성할 것이지만 거기에 무엇을 넣을 것입니까?

• 임의의 정수를 생성하고 그 중 하나가 소수가 될 때까지 반복하시겠습니까(또는 소수 생성 알고리즘을 당연히 실행)? 이런 종류의 제약 조건에서는 허용될 수 있지만 제약 조건을 준수하기가 더 까다롭다면 비용이 빠르게 들 것입니다.

• 허용 가능한 값의 유한 목록을 제공하시겠습니까?

글쎄, 불행히도 나는 여기에 은색 총알이 보이지 않으며 접근 방식은 상황에 따라 다릅니다. 값에 너무 무작위로 의존하지 않거나 단일 SUT가 1-2개의 소수만 사용하는 경우 소수를 하드코딩하고 소수 중에서 선택하는 것이 좋습니다( ElementsBulider<> 내장 도우미가 있습니다. 그러한 경우). 반면에 많은 소수 목록이 필요하고 긴 소수 시퀀스로 작업하는 경우 동적으로 생성하는 알고리즘을 코딩하는 것이 더 나을 것입니다.

또한, 이론적으로 개별적으로 임의적일 수 있는 여러 인수를 취하는 인스턴스를 만들려고 한다고 가정해 봅시다. true이고 argC는 argA 값에 따라 다른 유효성 검사 규칙을 준수해야 합니다. 그렇지 않으면 argC.X 속성이 argA.X 속성과 일치해야 합니다.

이 경우 어떻게 하시겠습니까?

정말 좋은 질문이고 불행히도 AutoFixture는 상자에서 꺼내는 좋은 방법으로 문제를 해결할 수 없습니다. 일반적으로 각 유형에 대한 사용자 정의를 분리하려고 하므로 한 유형에 대한 사용자 정의는 단일 유형에 대한 생성만 제어합니다. 그러나 제 경우에는 유형이 독립적이며 분명히 귀하의 경우에는 잘 작동하지 않을 것입니다. 또한 AutoFixture는 기본적으로 컨텍스트를 제공하지 않으므로 특정 유형에 대한 사용자 정의를 작성할 때 개체(내부적으로 표본이라고 함)를 생성하는 컨텍스트를 명확하게 이해할 수 없습니다.

내 머리 위에, 나는 일반적으로 다음과 같은 전략을 추천할 것이라고 말하고 싶습니다.

• 단일 개체 유형의 생성만 제어하는 ​​방식으로 각 유형에 대한 사용자 정의를 생성해 보십시오.
• 특정 제약 조건이 있는 종속성을 만들어야 하는 경우 사용자 지정에서도 해당 종속성을 활성화하는 것이 좋습니다. 종속성이 변경 가능한 경우 AutoFixture에 종속성을 생성하도록 요청하고 나중에 호환되는 방식으로 구성할 수 있습니다.

이렇게 하면 내부 아키텍처와 너무 많이 모순되지 않고 작동 방식이 명확해집니다. 물론 잠재적으로 이 방법은 매우 장황합니다.

복잡한 제약 조건이 있는 경우가 흔하지 않은 경우 기존 기능으로 충분할 수 있습니다. 그러나 도메인 모델이 이러한 경우로 가득 차 있다면 솔직히 AutoFixture가 최고의 도구가 아닐 수 있습니다. 아마도 시장에는 이러한 문제를 가장 우아한 방식으로 해결할 수 있는 더 나은 도구가 있을 것입니다. 물론 AutoFixture가 매우 유연하고 거의 모든 것을 재정의할 수 있으므로 AutoFixture 코어 위에 항상 고유한 DSL을 생성할 수 있다는 점을 언급할 가치가 있습니다... 하지만 어느 쪽이 더 저렴한지 평가해야 합니다 😉

@ploeh 에게도 그의 생각을 물어보자. 평소 마크의 답은 깊었고 결과를 해결하기 보다는 근본 원인을 먼저 찾아보려고 합니다 😅

더 궁금한 사항이 있으시면 질문해주세요! 나는 항상 그들에게 대답을 환영합니다.

PS FWIW, AutoFixture를 사용하여 유사한 문제를 해결하려고 시도한 샘플을 제공하기로 결정했습니다(간단하게 유지하려고 했지만 귀하의 경우에는 완전히 작동하지 않을 수 있음).

```c#
시스템 사용;
AutoFixture 사용;
AutoFixture.Xunit2 사용;
Xunit을 사용하여;

네임스페이스 AutoFixturePlayground
{
공용 정적 클래스 Util
{
공개 정적 bool IsPrime(int 번호)
{
// https://stackoverflow.com/a/15743238/2009373 에서 복사

        if (number <= 1) return false;
        if (number == 2) return true;
        if (number % 2 == 0) return false;

        var boundary = (int) Math.Floor(Math.Sqrt(number));

        for (int i = 3; i <= boundary; i += 2)
        {
            if (number % i == 0) return false;
        }

        return true;
    }
}

public class DepA
{
    public int Value { get; set; }
}

public class DepB
{
    public int PrimeNumber { get; }
    public int AnyOtherValue { get; }

    public DepB(int primeNumber, int anyOtherValue)
    {
        if (!Util.IsPrime(primeNumber))
            throw new ArgumentOutOfRangeException(nameof(primeNumber), primeNumber, "Number is not prime.");

        PrimeNumber = primeNumber;
        AnyOtherValue = anyOtherValue;
    }
}

public class DepC
{
    public DepA DepA { get; }
    public DepB DepB { get; }

    public DepC(DepA depA, DepB depB)
    {
        if (depB.PrimeNumber < depA.Value)
            throw new ArgumentException("Second should be larger than first.");

        DepA = depA;
        DepB = depB;
    }

    public int GetPrimeNumber() => DepB.PrimeNumber;
}

public class Issue1067
{
    [Theory, CustomAutoData]
    public void ShouldReturnPrimeNumberFromDepB(DepC sut)
    {
        var result = sut.GetPrimeNumber();

        Assert.Equal(sut.DepB.PrimeNumber, result);
    }
}

public class CustomAutoData : AutoDataAttribute
{
    public CustomAutoData() : base(() =>
    {
        var fixture = new Fixture();

        // Add prime numbers generator, returning numbers from the predefined list
        fixture.Customizations.Add(new ElementsBuilder<PrimeNumber>(2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41));

        // Customize DepB to pass prime numbers only to ctor
        fixture.Customize<DepB>(c => c.FromFactory((PrimeNumber pn, int anyNumber) => new DepB(pn, anyNumber)));

        // Customize DepC, so that depA.Value is always less than depB.PrimeNumber
        fixture.Customize<DepC>(c => c.FromFactory((DepA depA, DepB depB, byte diff) =>
        {
            depA.Value = depB.PrimeNumber - diff;
            return new DepC(depA, depB);
        }));

        return fixture;
    })
    {
    }
}

/// <summary>
/// A helper type to represent a prime number, so that you can resolve prime numbers 
/// </summary>
public readonly struct PrimeNumber
{
    public int Value { get; }

    public PrimeNumber(int value)
    {
        Value = value;
    }

    public static implicit operator int(PrimeNumber prime) => prime.Value;
    public static implicit operator PrimeNumber(int value) => new PrimeNumber(value);
}

}
```

안녕하세요 @zvirja

와, 자세한 답변 감사합니다, 정말 재미있습니다. 몇 가지 테스트를 수행하고 수행할 가치가 있는지 평가해야 하지만 이 모든 것이 훌륭합니다.

처리해야 할 종속성이 너무 많다고 생각하지 않으므로 귀하의 접근 방식이 좋은 방법일 수 있습니다. 물론 @ploeh 에서 추가할 사항이 있으면 영광입니다 👌

다시 한 번 감사합니다. 좋은 일을 계속하십시오!

AutoFixture 및 속성 기반 테스트에 대한 제 경험에 따르면 다음과 같은 문제를 해결하는 데는 기본적으로 두 가지 방법이 있습니다.

• 필터링
• 알고리즘 생성

(내가 쓰고 있는 동안 내 직관은 이것들이 각각 _catamorphisms_ 및 _anamorphisms_일 수 있다고 제안하지만, 나는 이것에 대해 좀 더 생각해야 할 것이므로 이것은 제쳐두고 대부분 나 자신에 대한 메모입니다.)

무작위로 생성된 값이 _대부분_ 안에 들어야 하는 제약 조건에 맞으면 기존 생성기를 사용하지만 가끔 부적합한 값을 버리는 것이 문제를 해결하는 가장 쉬운 방법이 될 수 있습니다.

반면에 필터가 대부분의 임의 데이터를 버리는 것을 의미하는 경우, 아마도 임의의 시드 값을 기반으로 문제의 제약 조건에 맞는 값을 생성하는 알고리즘을 제시해야 합니다.

몇 년 전에 저는 FsCheck 의 맥락에서 두 가지 접근 방식의 간단한 예를 보여주는 강연을 했습니다 . 이 프레젠테이션은 실제로 동일한 접근 방식을 취했지만 대신 AutoFixture를 사용하는 대화의 진화입니다. 불행히도 그 대화에 대한 녹음이 없습니다.

두 가지 방법으로 소수 요구 사항을 해결할 수 있습니다.

필터 접근 방식은 제약이 없는 숫자를 생성한 다음 실제로 소수가 될 때까지 숫자를 버리는 것입니다.

알고리즘 접근 방식은 소수 체와 같은 알고리즘을 사용하여 소수를 생성하는 것입니다. 그러나 이것은 무작위가 아니므로 임의화하는 방법을 알고 싶을 수 있습니다.

AutoFixture에서 제한된 값을 처리하는 방법에 대한 전반적인 질문은 다른 사람들이 라이브러리를 보기 시작하자 거의 즉시 제기되었으며 당시에도 여전히 참조하는 기사를 작성했습니다. http://blog.ploeh.dk/2009/ 05/01/제약 입력 처리

서로 관련된 여러 값에 대한 질문과 관련하여 일반적인 지침을 제공하고 싶지 않습니다. 그런 종류의 질문은 종종 XY 문제입니다. 많은 경우에 세부 사항을 이해하면 대체 설계가 AutoFixture뿐만 아니라 프로덕션 코드 기반 자체의 문제도 해결할 수 있습니다.

하지만 XY 문제가 있는 경우에도 이것이 정당한 문제가 될 수 있는 상황이 여전히 있을 수 있지만 내 경험에 따르면 문제를 사례별로 처리하고 싶습니다. 희귀 한.

따라서 이에 대한 구체적인 예가 있다면 제가 도움을 드릴 수는 있지만 일반적인 질문에 의미 있게 답할 수는 없을 것 같습니다.

@ploeh 이 답변에 감사드립니다. 이는 제가 고려하고 있던 접근 방식을 확인시켜줍니다.
상호 의존적인 값이 대부분 XY 문제라는 데 전적으로 동의합니다(적어도 제 경우에는). 문제는 레거시(테스트되지 않은 😢) 코드로 작업할 때 이러한 값을 처리하는 것이 우리가 얻을 때까지 어쨌든 몇 가지 테스트를 작성하는 좋은 시작이라는 것입니다. 이것을 제대로 리팩토링할 시간.

어쨌든 두 가지 답변 모두 문제를 아주 잘 해결하므로 거기에서 나가는 것이 좋습니다.
감사 해요!

BTW, 나는 @zvirja에 대한 추가로 내 대답을 의미했다는 것을 언급하는 것을 잊었습니다. 거기에 이미 좋은 답변입니다 👍

😄 다른 방법은 취하지 않았어요.