2009-11-08 10 views
5

Okej, więc próbowałem ostatnio wejść do IoC. Jednak ciągle napotykam na jedną przeszkodę - to jest fakt, że uwielbiam używać próbnych obiektów.Najlepsze praktyki w testach jednostkowych, próbnych obiektach i ioc

Są szybkie i bezbolesne w konfiguracji.

Jednakże, jeśli używam IoC w całym miejscu w moim kodzie, to zmusza mnie to do tworzenia implementacji testowych (i konfiguracji) moich obiektów zamiast używania obiektów próbnych (np. Za pomocą moq).

Rezultatem jest to, że mam do czynienia z ogromnymi plikami konfiguracyjnymi do testowania.

Ponadto istnieje wiele scenariuszy testowania, w których wymagam różnych zachowań z moich zajęć na zasadzie test-test. Dzięki obiektom moq jest to niezwykle łatwe. Jak zrobiłbyś coś podobnego z IoC?

Każda pomoc będzie mile widziana.

Dzięki,
Mike

+0

Czy możesz podać więcej informacji na temat problemu? Nie rozumiem, jak i dlaczego masz problem. Może próbka kodu? –

+0

Jeśli używasz wstrzyknięcia, zależności w twojej klasie powinny być zwykle wstrzykiwane do konstruktora lub właściwości - w twoim teście powinieneś mieć wszystkie szwy potrzebne do zastąpienia wstrzykniętego przez mocks. Czy możesz opracować konkretny przypadek, z którym walczysz? – Mathias

+0

Dlaczego, do licha, korzystasz z pojemnika IOC do testowania urządzenia? – mwjackson

Odpowiedz

5

IoC powinny zrobić za pomocą makiety obiektów łatwiejsze, nie ciężej.

Kilka ram kontenera IoC umożliwia zdefiniowanie wcześniej istniejących obiektów do wstrzyknięcia; z Moq właśnie ustawiłeś to dla myMockObject.Object.

Edycja: Przykład konfiguracji Unity z pozornie:

var mockService = new Mock<IMyService>(); 
container.RegisterInstance<IMyService>(mockService.Object); 

Alternatywnie, można po prostu przejść mock obiektu do konstruktora grupy badanej (do wstrzykiwań konstruktora) z pominięciem zbiornika IoC całkowicie w twoich testach jednostkowych.

EDYCJA: Odpowiedź Josha jest dobrym przykładem alternatywy. Generalnie chciałbym pójść z jego rozwiązaniem zamiast rekonfigurować kontener.

+0

Dobrze pokazuje, jak używać IoC do testowania. W końcu musieliśmy przetworzyć własny IoC do użycia z WCSF z kontekstu sieci. To było zaskakująco łatwe do zrobienia i zakończyło się znakomitym ćwiczeniem w zrozumieniu schematów Dependency Injection i IoC. – Josh

3

Kocham IoC i kocham mi jakieś atrapa obiektu ...

Nie ma konfliktu z tymi dwoma. Jeśli robisz coś w rodzaju Dependency Injection, powinieneś po prostu stworzyć fałszywe obiekty używając swojego ulubionego szyderstwa, a następnie przekazać je do swojego SUT.

[Test] 
public void AnAwesomeTest() 
{ 
    IDependencyOne d1 = MyMocker.Create<IDependencyOne>(); 
    IDependencyTwo d2 = MyMocker.Create<IDependencyTwo>(); 

    //Constructor injection 
    SUT sut = new SUT(d1); 

    //Property Injection 
    sut.DependantProperty = d2; 

    //Do some stuff and Assert 
} 
+0

+1. Zauważ, że byłby to "nowy SUT (d1.Object)" z Moq. – TrueWill

+0

Interesujące. Sam jestem przyzwyczajony do RhinoMocks ... jeśli składnia tego nie oddala. – Josh

+0

@Josh: Jedna różnica polega na tym, że d1 i d2 będą typu Mock . Minusem jest zrobienie .Obiekt, aby uzyskać interfejs, jest w stanie ustawić oczekiwania na d1 i d2 bezpośrednio. Warto porównywać/kontrastować biblioteki; mają różne filozofie. Zmieniłem się z Rhino na Moq jakiś czas temu. – TrueWill