Integracja a testy jednostkowe
Powinieneś zachować testy jednostkowe i testy integracyjne całkowicie osobne. Twoje testy jednostkowe powinny przetestować tylko jedną rzecz i całkowicie w izolacji od reszty systemu. Jednostka jest luźno zdefiniowana, ale zwykle sprowadza się do metody lub funkcji.
Sensowne jest przeprowadzenie testów dla każdej jednostki, abyś wiedział, że ich algorytmy są poprawnie zaimplementowane i od razu wiesz, co poszło nie tak, jeśli implementacja jest wadliwa.
Ponieważ podczas testowania jednostkowego testujesz w pełnej izolacji, używasz obiektów pośredniczących i próbnych, aby zachowywać się jak reszta aplikacji. W tym momencie pojawiają się testy integracyjne. Testowanie wszystkich jednostek w izolacji jest świetne, ale musisz wiedzieć, czy jednostki faktycznie działają razem.
Oznacza to wiedzieć, czy model jest rzeczywiście przechowywany w bazie danych, czy też naprawdę ostrzeżenie jest generowane po awarii algorytmu X.
Rozwój oparty na testach
Cofając się o krok i patrząc na Test Driven Development (TDD), należy wziąć pod uwagę kilka rzeczy.
- Test jednostkowy piszesz przed napisaniem kodu, który go powoduje.
- Wykonujesz test, piszesz tylko tyle kodu, aby to osiągnąć.
- Po przejściu testu czas cofnąć się o krok. Czy jest coś do refaktoryzacji dzięki tej nowej funkcjonalności? Możesz to zrobić bezpiecznie, ponieważ wszystko jest objęte testami.
Integracja pierwsza a integracja ostatnia
Testy integracyjne pasują do tego cyklu TDD na jeden z dwóch sposobów. Znam ludzi, którzy lubią je wcześniej pisać. Nazywają test integracji testem end-to-end i definiują test end-to-end jako test, który całkowicie testuje całą ścieżkę przypadku użycia (pomyśl o skonfigurowaniu aplikacji, ładowaniu jej, przechodzeniu do kontrolera, wykonywaniu go, sprawdzanie wyniku, danych wyjściowych itp.). Następnie zaczynają od pierwszego testu jednostkowego, sprawiają, że przechodzi, dodaje drugi, sprawiają, że przechodzi itp. Powoli coraz więcej części testu integracji również przechodzi, aż funkcja się zakończy.
Innym stylem jest budowanie testu jednostki funkcji po teście jednostki i dodawanie testów integracji, które zostaną uznane za konieczne później. Duża różnica między nimi polega na tym, że w przypadku testu integracyjnego najpierw musisz pomyśleć o projekcie aplikacji. Ten rodzaj nie zgadza się z założeniem, że TDD dotyczy zarówno projektowania aplikacji, jak i testowania.
Praktyczne
W mojej pracy mamy wszystkie testy w tym samym projekcie. Istnieją jednak różne grupy. Narzędzie do ciągłej integracji najpierw uruchamia to, co jest oznaczone jako testy jednostkowe. Tylko wtedy, gdy się to powiedzie, wykonywane są również wolniejsze (ponieważ wysyłają prawdziwe żądania, używają prawdziwych baz danych itp.) Testy integracyjne.
Nawiasem mówiąc, zwykle używamy jednego pliku testowego dla jednej klasy.
Sugerowane czytanie
- Rosnące oprogramowanie obiektowe oparte na testach Ta książka jest wyjątkowo dobrym przykładem pierwszej metodologii testu integracyjnego
- Sztuka testowania jednostkowego, z przykładami w dot.net. Testowanie jednostkowe, z przykładami w dot.net: D Bardzo dobra książka na temat zasad testowania jednostkowego.
- Robert C. Martin o TDD (darmowe artykuły): Przeczytaj również dwa pierwsze artykuły, które tam linkował.