Jak mogę zmodyfikować urządzenie, które mój niestandardowy atrybut danych teorii tworzy dla AutoFixture?

Question

Naprawdę doceniam moc AutoFixture w połączeniu z teoriami XUnita. Niedawno przyjąłem użycie encapsulating customizations i udostępniłem je moim testom za pomocą atrybutu.

Potrzebuję jednorazowego scenariusza do przeprowadzenia testu. Kiedy używam AutoDomainDataAttribute, jak wyżej, czy mogę poprosić o IFixture i spodziewać się tego samego wystąpienia utworzonego przez atrybut?

W moim scenariuszu domyślnie używam trybu wielokrotnej personalizacji dla kolekcji itp. Jednak w tym przypadku chcę, aby tylko jeden element został wysłany do mojego konstruktora SUT. Tak więc zdefiniowałem moją metodę testowania w następujący sposób:

[Theory, AutoDomainData] 
public void SomeTest(IFixture fixture) { 
    fixture.RepeatCount = 1; 
    var sut = fixture.CreateAnonymous<Product>(); 
    ... 
} 

Niestety, otrzymuję wyjątek podczas tworzenia anonimowego produktu. Inne testy działają dobrze, jeśli poproszę o produkt jako parametr metody z tymi atrybutami. Jest to tylko problem w tym konkretnym przypadku, w którym mam nadzieję, że parametr fixture jest taki sam, jak stworzony przez moją AutoDomainDataAttribute.

Konstruktor produktu oczekuje wartości IEnumerable, która zwykle zostanie wypełniona 3 elementami ze względu na modyfikacje, które mam na miejscu za pośrednictwem AutoDomainData. Obecnie moje DomainCustomization to CompositeCustomization składające się z MultipleCustomization i AutMoqCustomization, w tej kolejności.

Wyjątek: "InvalidCastException: nie można rzucić obiektu typu" Castle.Proxies.ObjectProxy ", aby wpisać" Produkt "."

Answer 1

Jeśli potrzebujesz tego samego wystąpienia światła jako jednej czynnej w atrybucie można wstrzykiwać uchwytu do siebie w personalizacji, tak:

public class InjectFixtureIntoItself : ICustomization 
{ 
    public void Customize(IFixture fixture) 
    { 
     fixture.Inject(fixture); 
    } 
} 

Wystarczy pamiętać, aby dodać do swojej CompositeCustomization przed AutoMoqCustomization, ponieważ IFixture jest interfejsem, a jeśli AutoMoqCustomization jest na pierwszym miejscu, zamiast tego otrzymasz instancję Mock - AFAICT, to właśnie dzieje się z dynamicznym proxy Castle.

---

Jeśli jednak naprawdę potrzebują instancję Fixture, dlaczego nie wystarczy napisać regularną, imperatyw metody badawczej:

[Fact] 
public void SomeTest() 
{ 
    var fixture = new Fixture().Customize(new DomainCustomization()); 
    fixture.RepeatCount = 1; 
    var sut = fixture.CreateAnonymous<Product>(); 
    // ... 
} 

Wydaje mi się, że o wiele łatwiej ... I od czasu do czasu to zrobić ja też ...

---

Wciąż zastanawiam się, czy nie można było wyrażenie Twój API lub przypadek testowy w inny sposób, aby cały problem znika. I very Bardzo rzadko zauważam, że muszę obecnie manipulować nieruchomościami RepeatCount, więc zastanawiam się, dlaczego chciałbyś to zrobić?

Prawdopodobnie jest to temat osobnego pytania dotyczącego przepełnienia stosu, jednak ...