Czy koniec 2 testu wystarczy?

Question

Moje pytania dotyczą głównie metodologii testowania. Pracuję dla organizacji, która zajmuje się TDD (Test Driven Development). Używamy AngularJS, a więc jego pełnego stosu testowego - Jasmine do testów jednostkowych i Kątomierza do testowania e2e.

Przy opracowywaniu obiektu nasz proces rozpoczyna się od napisania najpierw nieudanych testów e2e, a następnie zapisania funkcji za pomocą TDD. Testy są pisane tylko dla publicznych metod (czy to dla kontrolera/dyrektyw/usług). Sam produkt nie zawiera żadnej złożonej logiki (oprócz kilku wyjątków). Niedawno zaczęliśmy rozmawiać o tym, że pisanie testów jednostkowych dla kontrolerów nie ma sensu, ponieważ eksponują funkcjonalność, w 100% są wystawiane na widok i testowane przy użyciu testów e2e. Zasadniczo - testy jednostkowe i testy e2e nakładają się. Na początku wszyscy się zgodziliśmy, ale wtedy ta decyzja otworzyła pudełko Pandory. W końcu to samo można powiedzieć o dyrektywach. Dlaczego więc je testować? Potem pojawiła się kwestia usług. Większość z nich (98%) wykonuje po prostu wywołanie zwrotne i zwraca odpowiedź. Dlaczego więc nie po prostu pozorować httpBackend i przetestować usługi podczas testowania kontrolerów, które są testowane przez e2e.

dostać dryfu ....

ja widzę korzyści w sposób zarówno testy jednostkowe i testy e2e, pomimo ich praktycznie pokrywają. Głównie - natychmiastowa informacja zwrotna i "wykonywalna dokumentacja". Co praktykujesz? Czy widzisz inne korzyści i to "sok wart wyciskania" - czy warto pisać nakładające się testy dla najprostszych implementacji tylko po to, aby uzyskać te dwie korzyści powyżej?

Answer 1

To jest duży temat, a nie coś, co naprawdę może mieć autorytatywną odpowiedź, ale dołożę wszelkich starań, aby omówić kilka kwestii.

Po pierwsze, powinieneś pomyśleć o celu testów. Zgodnie z Agile Testing Quadrants, testy jednostkowe istnieją głównie w celu wsparcia zespołu. Są generalnie napisane blisko produktu (np. Przy użyciu TDD, prawdopodobnie przez samych programistów) i służą zwiększeniu pewności, że deweloper nie złamał nic z tą ostatnią zmianą. Z tą pewnością twórcy mogą efektywnie pracować i refaktoryzować się lekkomyślnym abadonem - marzeniem TDD. Testy jednostkowe nie odpowiadają na pytanie "Czy jest to zgodne z celem klienta", ale nie dlatego tak się dzieje.

Testy funkcjonalne (e2e, jeśli rozumiem twój opis) nadal wspiera zespół z szybkim odwracaniem wyników testów, ale faktycznie zaczynają odpowiadać na pytanie "Czy użytkownik może to zrobić?". Testujesz to, co widzi użytkownik i zaczynasz testować rzeczywisty produkt w sposób znaczący dla użytkowników.

Ćwiartki 3 i 4 zaczynają odnosić się do tego, czy produkt działa prawidłowo, czy nie, czy nie, czy nie, czy też nie, jest to nie tylko funkcjonalne, ale jest to inny temat.

W oparciu o to zrozumienie testu, część odpowiedzi zależy od struktury zespołu. Czy masz oddzielny zespół programistów i testerów? Jeśli tak, to może mieć sens dla twoich twórców pisania testów jednostkowych (są one dla nich korzystne) i dla zespołu testowego do samodzielnego obsługiwania pozostałych kwadrantów (w tym pisanie e2e zgodnie z ich wolą). A jeśli twój test i zespół deweloperski są takie same? Jeśli możesz uzyskać podobny czas realizacji (test pisemny -> użyteczny wynik) z testów funkcjonalnych/e2e, jak to możliwe z testów jednostkowych, może warto skoncentrować się na nich i zebrać nagrody za obie metody bez nakładania się.

Krótka odpowiedź, jaką chciałbym podać, to po prostu zapytać: "Jakie korzyści daje opuszczenie tego testu?".Jeśli uznasz, że twoje odpowiedzi na testy nakładają się, może być przydatne usunięcie nadmiarowości.

Niektóre z powyższych punktów i kilka innych są omówione here, więc na razie przestanę się włóczyć.