Autofixture: Customization 기반 Random 시편 생성 방식

이것은 스택 오버플로 질문에 대한 좋은 후보처럼 보입니다. 여기에 질문하는 것이 잘못된 것은 아니지만 이 질문은 답변이 다른 사람들에게도 도움이 될 수 있는 종류이고 GitHub 문제에 비해 Stack Overflow에서 질문과 답변을 찾는 것이 더 쉽다고 생각합니다. 예를 들어, Google은 스택 오버플로 질문에 대한 인덱싱을 잘 수행하지만 GitHub 문제의 순위는 (닫힌) 더 낮은 것 같습니다...

@ploeh 공감합니다....
방금 이 문제를 기반으로 SO 질문을 만들었습니다. 추후 참고할 수 있는 링크 입니다 👍

@ploeh SO :blush에 대한 질문에 답변해 주셔서 감사합니다.

@thiagomajesk 실제로 여기에 질문에 답하는 데 문제가 없습니다. Mark가 SO를 제안한 이유는 그것이 제공하는 검색 기능 때문입니다. 또한 현재 Mark는 SO를 모니터링하고 있으므로 거기에 질문을 게시하면 그의 전문 지식을 얻을 수 있는 더 많은 기회가 있습니다(이번에 얻은 것처럼) :sweat_smile:

@zvirja 설명 해주셔서 감사합니다 😄

@zvirja @ploeh 의 훌륭한 답변을 기반으로 SO에 대한 질문을 마무리하겠습니다 .
하지만 이에 대한 구현 세부 정보에 대해 조금 더 알고 싶습니다.
주제에서 더 이상 벗어나고 싶지 않기 때문에 여기에서 이 세부 사항에 대해 묻는 것이 더 나을 것 같습니다. 그래서 나는이 구현이 있습니다 :

```c#
공개 클래스 UniqueShortGuidBuilder: ISpecimenBuilder
{
개인 읽기 전용 문자열 propName;
개인 읽기 전용 int 길이;

public UniqueShortGuidBuilder(Expression<Func<TEntity, string>> expr, int lenght)
{
    propName = ((MemberExpression)expr.Body).Member.Name;
    this.lenght = lenght;
}

공용 객체 생성(객체 요청, ISpecimenContext 컨텍스트)
{
var pi = PropertyInfo로 요청;

if (pi == null || pi.PropertyType != typeof(string) || pi.Name != propName)
    return new NoSpecimen();

return Guid.NewGuid().ToString().Substring(0, lenght);

}
```

AutoFixture로 많은 개체를 생성할 때 ISpecimenBuilder.Create 가 여러 번 호출되어 내 엔티티에 대해 고유한 Guid가 생성될 것으로 예상했습니다. 그러나 분명히 이것은 사실이 아니며 실제로 동일한 것을 공유하고 있습니다.

글쎄요, 방금 귀하의 코드를 테스트했으며 원하는 대로 정확하게 작동했습니다.

```c#
공개 클래스 푸
{
공개 문자열 PropertyToCustomize { 가져오기; 세트; }
}

공개 클래스 UniqueShortGuidBuilder: ISpecimenBuilder
{
개인 읽기 전용 문자열 propName;
개인 읽기 전용 int 길이;

public UniqueShortGuidBuilder(Expression<Func<TEntity, string>> expr, int lenght)
{
    propName = ((MemberExpression) expr.Body).Member.Name;
    this.lenght = lenght;
}

public object Create(object request, ISpecimenContext context)
{
    var pi = request as PropertyInfo;

    if (pi == null || pi.PropertyType != typeof(string) || pi.Name != propName)
        return new NoSpecimen();

    return Guid.NewGuid().ToString().Substring(0, lenght);
}

}

[사실]
공개 무효 TestCustomization()
{
var 고정 장치 = new Fixture();
Fixture.Customizations.Add(new UniqueShortGuidBuilder(x => x.PropertyToCustomize, 5));

var manyFoos = fixture.CreateMany<Foo>(10);

var uniqueIds = manyFoos
    .Select(x => x.PropertyToCustomize)
    .Where(x => x.Length == 5)
    .Distinct()
    .ToArray();
Assert.Equal(10, uniqueIds.Length);

}
```

따라서 실제 코드가 어떻게 다른지 다시 확인하여 그 차이가 중요한 이유를 이해할 수 있도록 하고 싶습니다. 😟

@zvirja 이상
Fixture.Customize(new FooCustomization()); 하면 테스트가 통과하고 그렇지 않으면 통과하지 못합니다.

```c#
시스템 사용;
Microsoft.VisualStudio.TestTools.UnitTesting 사용;
AutoFixture.Kernel 사용;
System.Linq.Expressions 사용;
System.Reflection 사용;
AutoFixture 사용;
System.Linq를 사용하여;

네임스페이스 UnitTestProject1
{
공개 클래스 푸
{
공개 문자열 PropertyToCustomize { 가져오기; 세트; }
}

public class FooCustomization : ICustomization
{
    public void Customize(IFixture fixture)
    {
        var specimen = fixture.Build<Foo>()
            .OmitAutoProperties()
            .With(x => x.PropertyToCustomize)
            .Create();

        fixture.Register(() => specimen);
    }
}

public class UniqueShortGuidBuilder<TEntity> : ISpecimenBuilder
{
    private readonly string propName;
    private readonly int lenght;

    public UniqueShortGuidBuilder(Expression<Func<TEntity, string>> expr, int lenght)
    {
        propName = ((MemberExpression)expr.Body).Member.Name;
        this.lenght = lenght;
    }

    public object Create(object request, ISpecimenContext context)
    {
        var pi = request as PropertyInfo;

        if (pi == null || pi.PropertyType != typeof(string) || pi.Name != propName)
            return new NoSpecimen();

        return Guid.NewGuid().ToString().Substring(0, lenght);
    }
}

[TestClass]
public class UnitTest1
{
    public static Fixture Fixture { get; private set; }

    [ClassInitialize]
    public static void ClassInitialize(TestContext context)
    {
        Fixture = new Fixture();
        Fixture.Customizations.Add(new UniqueShortGuidBuilder<Foo>(x => x.PropertyToCustomize, 5));
        Fixture.Customize(new FooCustomization());
    }

    [TestMethod]
    public void TestMethod1()
    {
        var manyFoos = Fixture.CreateMany<Foo>(10);

        var uniqueIds = manyFoos
            .Select(x => x.PropertyToCustomize)
            .Where(x => x.Length == 5)
            .Distinct()
            .ToArray();

        Assert.AreEqual(10, uniqueIds.Length);
    }
}

}
```

권장 사항: GUID 문자열에서 처음 _n_자를 사용하는 경우 클래스 이름을 UniqueShortGuidBuilder 지정하지 마십시오. 길이가 5이면 값이 상당히 고유할 수 있지만 1로 설정하면 충돌이 발생할 수 있습니다. 어쨌든 고유성은 보장되지 않습니다.

문자열의 길이와 보장되지 않은 고유성에 관심이 있다면 AutoFixture에 예를 들어 0에서 99,999 사이의 숫자를 요청하고 이를 문자열로 바꾸면 어떨까요? IIRC, 숫자는 범위가 소진될 때까지 고유합니다.

Fixture.Customize(new FooCustomization()); 테스트는 통과하고 그렇지 않으면 통과하지 못합니다.

뭐, 사실 상황을 잘 살펴보시면 예상되는 행동입니다 😂 #962 에서 제 답글 을 봐주세요. 제공된 FooCustomization 구현은 Foo 유형의 인스턴스를 생성하고 항상 해당 인스턴스를 반환하도록 조명기를 구성합니다. 따라서 나중에 Foo 유형의 여러 인스턴스를 만들 때 동일한 개체가 반환되고 빌더가 더 이상 호출되지 않을 때마다.

Foo 를 요청할 때마다 새 인스턴스를 생성하려면 여기에서 제안한 대로 Customize<> API를 사용 하십시오 .

@ploeh 팁을 주셔서 감사합니다. 하지만 그 코드는 테스트 목적을 위한 총체적인 예일 뿐입니다. 실제 경우 길이는 Guids의 고유성에 영향을 줄 정도로 짧지 않습니다 😄.

문자열의 길이와 보장되지 않은 고유성에 관심이 있다면 AutoFixture에 예를 들어 0에서 99,999 사이의 숫자를 요청하고 이를 문자열로 바꾸면 어떨까요?

나는 이것이 대부분의 경우에 좋은 솔루션이라고 확신하지만 내 시스템의 영숫자 유효성 검사 때문에 이 특정한 경우에는 그렇게 할 수 없습니다. 그 외에도 해당 필드와 관련된 더 복잡한 유효성 검사가 있습니다.

글쎄요, 사실 상황을 좀 더 자세히 살펴보면 예상되는 행동입니다.

@zvirja #962에서 답장을 여기서 지적한 것처럼) 그 행동이 분명하지 않았습니다. 😁.

마무리로 인내심과 모든 훌륭한 설명에 감사드립니다.
나는 이것이 미래에 다른 사람들에게도 유용할 것이라고 확신합니다 😉.

좋아, 충분히 공평하게, 나는 일을 너무 문자 그대로 받아들이는 경향이 있을지도 모른다 😄