Wstrzykiwanie zależności do testów

Question

Zwykle podczas korzystania z iniekcji zależności, testy jednostkowe (i inne) są odpowiedzialne za tworzenie/szykanowanie zależności testowanego systemu i wstrzykiwanie ich.

Czasami jednak sam test ma zależności lub wymaga wstrzyknięcia zależności do SUT, których sam nie może utworzyć. Na przykład podczas testowania klas, które współdziałają z bazą danych, test musi znać ciągi połączeń i nazwy katalogów itp., Które nie mogą być zakodowane na sztywno, ponieważ niekoniecznie są takie same dla każdego, kto wykonuje test.

Więc jak poleciłbyś testowi sprawdzić te ustawienia? Czy niektóre szkielety testowe w stylu xUnit zapewniają sposób na uzależnienie urządzenia testowego? Czy klasa testowa ma właściwości statyczne, które wypełniasz przed uruchomieniem wszystkich testów? Czy test powinien ignorować praktyki DI i po prostu iść i uzyskać zależności od jakiegoś globalnego miejsca? Inne sugestie?

Answer 1

Kiedy używasz testowania ramy urządzenia, aby zrobić testy integracyjne, tak naprawdę nie mają DI lub problem testów jednostkowych.

Co to są testy integracyjne, które wykorzystują zaawansowany system testów jednostkowych.

Ponieważ są to testy integracyjne, różnią się rodzajami od testów jednostkowych. "Samodzielny-Ness" tak naprawdę już nie liczy.

Najlepszym sposobem uzyskania ustawień testu integracji różniących się w zależności od użytkownika jest uzyskanie ich w taki sam sposób, w jaki otrzyma je końcowa aplikacja. Jeśli pracujesz w Javie, możesz mieć plik właściwości. W Pythonie mamy specjalne pliki ustawień Django do testowania integracji.

Answer 2

Istnieje zasada dla w pełni zautomatyzowanych testów: powinieneś być w stanie ściągnąć cały kod źródłowy z repozytorium kontroli kodu źródłowego i po prostu uruchomić testy.

Biorąc pod uwagę, że środowisko (maszyna) ma odpowiednią bazę instalacyjną (tj. Kompilator, szkielet testowy, silnik bazy danych, jeśli ma to zastosowanie, itp.) Testy są odpowiedzialne za konfigurację ich Urządzenia przed wykonaniem przypadków testowych.

Oznacza to, że w przypadku baz danych, testy powinny

1. utworzyć bazę danych w pytaniu
2. prowadzony jej testy
3. usunąć bazę danych ponownie po ostatnim przypadku testowego

Jeśli z jakiegoś powodu nie możesz tego zrobić, jedyną rzeczą, którą naprawdę możesz zrobić, to mieć plik konfiguracyjny w systemie kontroli źródła, który zawiera wpisy specyficzne dla maszyny dla wszystkich komputerów w twoim testowaniu invironment; na przykład w przypadku maszyny Tst1 ciąg połączenia jest jedną wartością, ale dla Tst2 jest to kolejna.

To może stać się brzydkie bardzo szybko, więc testowanie Fixture i Teardown jest o wiele łatwiejsze, ponieważ oznacza to, że mogą po prostu użyć zakodowanych wartości lub wartości generowanych na miejscu.

To naprawdę nie ma nic wspólnego z DI ...

Answer 3

DI walczy z dependecies złożoności, a twoje testy jednostkowe muszą być przez większość czasu bardzo prosta. Typowy test jednostkowy bada jeden wyizolowany aspekt jednej wyizolowanej klasy. Zamiast wszystkich jego zależności tworzysz makiety i (zwykle) wstrzykujesz je przez konstruktor CUT (Class Under Test). Zazwyczaj nie potrzebujesz tutaj frameworka DI.

Ale. Niektóre testy wyższego poziomu mogą oczywiście wymagać nieskrępowanych zależności. Na przykład, chcesz wykonać testy na dużym zestawie danych i nie chcesz tworzyć specjalnego fałszywego źródła danych, więc trzymasz je w prawdziwym DB (możesz też wykonać niektóre testy interfejsu z tymi danymi). W takim przypadku nadal starałbym się utrzymywać rzeczy tak proste, jak to tylko możliwe, inicjując testy w metodach konfiguracji klas/testowania.

Widzisz, musisz być ostrożny tutaj.Ilekroć wykonujesz duży, skomplikowany test:

1. Utwórz dodatkowy skomplikowany kod, który będzie wymagał wsparcia technicznego.
2. Utwórz test, który nie ma wyraźnego powodu niepowodzenia. To może się nie udać z powodu złej łączności w tym dniu. Nie można polegać na jego wyniku.
3. Utwórz test, którego nie można uruchomić łatwo i szybko, na przykład przy odprawie. Mniej osób go uruchomi, więcej błędów przejdzie.

etc ...