Unit Testing streszczenie fabryka, która pobiera parametry

Question

otrzymał abstrakcyjne realizację fabryczną:

public class FooFactory : IFooFactory { 
    public IFoo Create(object param1, object param2) { 
     return new Foo(param1, param2); 
    } 
} 

Jakie badania jednostka będzie napisany dla tej klasy? Jak mogę sprawdzić, czy param1 i param2 zostały przekazane do utworzenia Foo? Czy muszę tworzyć te publiczne właściwości Foo? Czy to nie złamałoby hermetyzacji? Czy powinienem to zostawić testom integracyjnym?

Answer 1

Oto jak chciałbym napisać jedną z kilku testów jednostkowych do takiego zakładu (z xUnit.net):

[Fact] 
public void CreateReturnsInstanceWithCorrectParam1() 
{ 
    var sut = new FooFactory(); 
    var expected = new object(); 
    var actual = sut.Create(expected, new object()); 
    var concrete = Assert.IsAssignableFrom<Foo>(actual); 
    Assert.Equal(expected, concrete.Object1); 
} 

Czy przerwać hermetyzacji? Tak i nie ... trochę. W enkapsulacji nie chodzi tylko o ukrywanie danych - co ważniejsze, jest to około protecting the invariants of objects.

Załóżmy, że Foo eksponuje tę publicznego API:

public class Foo : IFoo 
{ 
    public Foo(object param1, object param2); 

    public void MethodDefinedByInterface(); 

    public object Object1 { get; } 
} 

Podczas gdy nieruchomość Object1 lekko naruszyć Law of Demeter, to nie bałagan z niezmienników klasy, ponieważ jest tylko do odczytu.

Ponadto nieruchomość Object1 jest częścią betonu klasy Foo - nie interfejs IFoo:

public interface IFoo 
{ 
    void MethodDefinedByInterface(); 
} 

Kiedy zdajesz sobie sprawę, że w luźno API, concrete members are implementation details takie konkretne tylko do odczytu tylko obiekty bardzo mały wpływ na enkapsulację. Pomyśl o tym w ten sposób:

publiczna konstruktor Foo jest również częścią API betonu klasy Foo, więc po prostu sprawdzając publicznych API, dowiadujemy się, że param1 i param2 są częścią klasy. W pewnym sensie to już "przerywa enkapsulację", więc udostępnienie każdego parametru jako właściwości tylko do odczytu na konkretnej klasie niewiele się zmienia.

Dzięki tym właściwościom możemy teraz jednostce przetestować konstrukcyjny kształt klasy Foo zwróconej przez fabrykę.

Jest to znacznie łatwiejsze niż powtarzanie zestawu behawioralnych testów jednostkowych, które, jak możemy przyjąć, obejmują już konkretną klasę Foo. To prawie jak logiczny dowód:

1. Z testów konkretnej klasy Foo wiemy, że poprawnie używa/współdziała z jej parametrami konstruktora.
2. Z tych testów wiemy również, że parametr konstruktora jest wyświetlany jako właściwość tylko do odczytu.
3. Z testu FooFactory wiemy, że zwraca instancję konkretnej klasy Foo.
4. Ponadto, z testów metody Create wiemy, że jej parametry są poprawnie przekazywane do konstruktora Foo.
5. Q.E.D.

Answer 2

Można uczynić FooFactory klasą ogólną, która oczekuje Foo jako parametru i określić, że jest to makiety. Wywołanie fabryki. Stwórz (...) następnie stwórz instancję próbną, a następnie możesz potwierdzić, że fałszywa otrzymała oczekiwane argumenty.

Answer 3

To zależy od tego, co Foo robi z 2 obiektami wejściowymi. Sprawdź, co robi z nimi Foo, na które łatwo można się natknąć. Na przykład, jeśli metody (w tym metody pobierające lub ustawiające) są wywoływane na obiektach, podaj mocks lub kody pośredniczące, które możesz zweryfikować, gdy wywołane zostaną oczekiwane rzeczy. Jeśli istnieje coś na IFoo, które można przetestować przeciwko, możesz przekazać znane wartości za pomocą fałszywych obiektów, aby sprawdzić po utworzeniu. Obiekty nie powinny być publicznie dostępne, aby sprawdzić, czy je przeszedł.

Mogę również sprawdzić, czy oczekiwany typ (Foo) jest zwracany, w zależności od tego, czy inne testowane zachowania zależą od różnicy między implementacjami IFoo.

Jeśli wystąpią jakiekolwiek warunki błędu, spróbuję je również wymusić, co się stanie, jeśli przekażesz null dla jednego lub obu obiektów, itp. Foo byłoby testowane osobno, więc może założyć podczas testu FooFactory, że Foo robi to, co powinien.

Answer 4

Fabryki zazwyczaj nie są testowane na jednostkach, przynajmniej według mojego doświadczenia - nie ma zbyt wiele wartości w jednostkach testujących je. Ponieważ jest to implementacja tego mapowania implementacji interfejsu, stąd odnosi się do konkretnej implementacji. W związku z tym nie można sprawdzić, czy odbiera te parametry przekazane.

Z drugiej strony, zwykle kontenery DI działają jak fabryki, więc jeśli używasz jednego, nie potrzebujesz fabryki.

Answer 5

Cóż, prawdopodobnie te parametry sprawiają, że zwracany IFoo ma coś prawdziwego na ten temat. Sprawdź, czy to prawda w odniesieniu do zwróconego wystąpienia.