Testy kompleksowe a testy jednostkowe, czy należy oddzielić testy?

W naszej firmie zazwyczaj upewniamy się, że piszemy kompleksowy test dla naszych stron internetowych / aplikacji internetowych. Oznacza to, że uzyskujemy dostęp do adresu URL, wypełniamy formularz, przesyłamy formularz na inny adres URL i sprawdzamy wyniki strony. Robimy to w celu przetestowania weryfikacji formularza, sprawdzenia, czy szablony HTML mają poprawne zmienne kontekstowe itp.

Używamy go również do pośredniego testowania podstawowej logiki.

Współpracownik powiedział mi, że powodem tego jest to, że możemy zerwać i zmienić implementację bazową w dowolnym momencie, pod warunkiem, że przejdą testy end-to-end.

Zastanawiam się, czy tego rodzaju odsprzęganie ma sens, czy to tylko sposób na uniknięcie pisania testów dla mniejszych jednostek kodu?

Niezbędne są również kompleksowe testy. Skąd jeszcze możesz wiedzieć, że poprawnie połączyłeś wszystkie jednostki? Na bardzo prostym kodzie możliwe jest przetestowanie wszystkich ścieżek w kodzie za pomocą tylko testów end-to-end, ale gdy otrzymujesz więcej warstw, staje się to zbyt kosztowne.

Załóżmy na przykład, że masz trzy warstwy, każda z pięcioma możliwymi ścieżkami. Testowanie wszystkich ścieżek w całej aplikacji wymagałoby 5 ³ kompleksowych testów, ale można przetestować wszystkie ścieżki w każdej jednostce za pomocą jedynie 5 · 3 testów jednostkowych. Jeśli wykonujesz tylko testy end-to-end, wiele ścieżek zostaje zaniedbanych, głównie w zakresie obsługi błędów i warunków brzegowych.

Tak, testy end-to-end (lub testy integracyjne) mają sens, ale także testy jednostkowe. Najlepiej, jeśli masz je oba, ponieważ oba zazwyczaj łapią różnego rodzaju błędy. Zatem posiadanie kompleksowych testów nigdy nie powinno być usprawiedliwieniem dla braku testów jednostkowych.

Po kilku latach programowania i pracy nad projektami udzielę odpowiedzi na moje własne pytanie.

Tak, powinieneś napisać testy jednostkowe. Testy od końca do końca są trudniejsze do napisania i kruche, zwłaszcza jeśli polegają na składnikach interfejsu użytkownika.

Jeśli używasz frameworka, takiego jak Django lub Rails (lub własne niestandardowe klasy), powinieneś mieć klasę formularza, która będzie obsługiwać sprawdzanie poprawności formularza. Będziesz także mieć klasy widoku, które wyświetlają renderowane szablony oraz formularz i obsługują żądania GET i POST.

W ramach testu od końca do końca:

1. pobierz adres URL
2. wypełnij formularz prawidłowymi danymi
3. opublikuj formularz na adres URL
4. sprawdź, czy baza danych została zaktualizowana lub czy jakieś działanie zostało wykonane w wyniku prawidłowego formularza

Testujesz dużo kodu i zasięg będzie całkiem dobry, ale testujesz szczęśliwą ścieżkę tylko wtedy, gdy wszystko pójdzie dobrze. W jaki sposób upewniasz się, że formularz ma odpowiednią weryfikację? Co jeśli ten formularz jest używany na wielu stronach? Czy piszesz jeszcze jeden test od końca do końca?

Spróbujmy jeszcze raz z testami jednostkowymi:

1. przetestuj metodę GET widoku
2. przetestuj metodę POST widoku za pomocą fałszywego / próbnego formularza
3. przetestuj formularz z poprawnymi danymi
4. przetestuj formularz z nieprawidłowymi danymi
5. przetestuj skutki uboczne formularza

Korzystając z testów jednostkowych, testujesz mniejsze fragmenty kodu, a testy są specyficzne i łatwiejsze do napisania. Połączenie tego z TDD (Test Driven Development) daje kod o wyższej jakości.

Łatwość pisania testów jednostkowych nie powinna zostać odrzucona, ponieważ jeśli pracujesz nad projektem, który nie ma testów automatycznych, musisz gdzieś zacząć. Rozpoczęcie od testów jednostkowych jest łatwiejsze i szybsze i pozwala natychmiast rozpocząć testowanie pod kątem błędów, a nie tylko szczęśliwej ścieżki.

W rzeczywistości testy kompleksowe lub testy integracyjne są ważniejsze niż testy jednostkowe, ponieważ zapewniają, że masz w pełni działający system. Testy jednostkowe nie obejmują części integracyjnej systemu, co jest skomplikowanym zadaniem, szczególnie w dużych projektach.

Jednak, jak już powiedziano, powinieneś również przeprowadzać testy jednostkowe, ponieważ bardziej skomplikowane jest wychwycenie przypadków skrajnych w testach integracyjnych.

Weryfikuje zachowanie systemu, podczas gdy testy jednostkowe weryfikują zachowanie urządzenia. Korzyści i koszty dla każdego są różne. Możesz zrobić jedno lub drugie albo jedno i drugie.

W mojej pracy wykonujemy rozwój oparty na testach akceptacyjnych bez testów jednostkowych, co brzmi podobnie do tego, co opisałeś. Z czasem zaczęliśmy robić jedno i drugie, ostatecznie wyeliminowaliśmy testy jednostkowe, których koszt przekraczałby dla nas korzyści.

Biorąc to pod uwagę, uważam, że koszt / korzyść dla Twojej problematycznej domeny i środowiska powinna wpływać na decyzje o zaangażowaniu się w dowolną praktykę programistyczną, w tym różne praktyki automatycznego testowania. Zamiast wiary wolę, aby wszystkie praktyki miały dowody empiryczne w kontekście ich użycia, aby je poprzeć.