Testy sparametryzowane - kiedy i dlaczego ich używasz?

Ostatnio w pracy mamy pewne różnice zdań w odniesieniu do testowania sparametryzowanego . Zwykle używamy stylu TDD (lub przynajmniej próbujemy), więc rozumiem zalety tego podejścia. Walczę jednak, by przynieść sparametryzowane testy wzmocnienia. Dla odniesienia pracujemy nad usługą i jej bibliotekami, które są udostępniane przez interfejs RESTful.

Do tej pory widziałem testy, które przynajmniej wykorzystują JUnit w Eclipse:

• Brak szczegółów - gdy test się nie powiedzie, bardzo trudno jest dostrzec parametry, które go spowodowały
• Często skomplikowane w tworzeniu
• Zwykle są tworzone po napisaniu kodu - absolutnie nie jest to wada sama w sobie, ale czy ludzie wyruszają z myślą o sparametryzowanych testach, kiedy zaczynają fragment kodu?

Jeśli ktoś ma jakieś przykłady tego, gdzie są naprawdę przydatne, lub nawet jakieś dobre wskazówki, jak z nich korzystać, byłoby fantastycznie. Chcę się upewnić, że nie jestem uparty, ponieważ osobiście nie wybieram ich używania i sprawdzam, czy są czymś, co powinniśmy rozważyć, biorąc udział w naszym arsenale testowym.

Problem z testowaniem dowolnego oprogramowania polega na tym, że złożoność rozwija się dość szybko. Faktem jest, że nie można przetestować wszystkich możliwych kombinacji parametrów przekazanych do metod. Phadke opowiada się za podejściem do projektowania eksperymentów (DOE), które umożliwia generowanie prawdopodobnej listy wartości parametrów, które należy przetestować.

Chodzi o to, że nawet jeśli nie przeprowadzasz wyczerpujących testów, większość defektów powoduje pojawienie się „obszaru uszkodzenia”, a nie uszkodzenia pojedynczego punktu. Podejście DOE Phadke opowiada się za wykorzystaniem tablic ortogonalnych próbkujących przestrzeń parametrów wystarczająco dokładnie, aby trafić we wszystkie możliwe obszary błędów.

Pojedyncze uszkodzenia prawdopodobnie nie zostaną zidentyfikowane, ale na ogół jest ich mniej niż obszary uszkodzeń.

Podejście DOE zapewnia systematyczny sposób wyboru wartości parametrów do zmiany.

Mogą być przydatne do zapewnienia, że ​​Twój kod obsługuje nie tylko ścieżkę szczęśliwą, ale także przypadki brzegowe. Gdy już wiesz, że Twój kod działa ze zmiennymi normalnymi, sparametryzuj przypadek testowy i upewnij się, że wartości zerowe i zerowe, puste ciągi, duże liczby, długie ciągi, dziwne znaki Unicode itp. Również działają dobrze.

Istnieją co najmniej dwa warianty sparametryzowanych testów, przynajmniej w JUnit 4.8. Są to: Testy sparametryzowane ( @RunWith(Parameterized.class)), które wymagają źródła danych, które generuje / odczytuje predefiniowane konfiguracje parametrów, oraz Teorie ( @RunWith(Theories.class)), które przy danym jednym lub większej liczbie możliwych danych wejściowych dla każdego typu argumentu mogą wykonywać specyfikację danych metod. Wygląda mniej więcej tak:

• podaj możliwe wartości ( @DataPoints) dla argumentów ciągu (np. nullpusty ciąg, niepusty ciąg, naprawdę długi ciąg)
• podać kilka możliwych wartości ( @DataPoints) dla argumentów klasy zwierzę (jak null, Doginstancja, Catinstancja, Birdnp)
• przygotuj, @Theoryktóry akceptuje Stringparametr i Animalparametr. zostanie wykonany z każdą możliwą kombinacją możliwych wartości parametrów (w podanym przykładzie byłoby to 4x4 = 16 kombinacji, w tym ( null, null))
• jeśli testowana metoda nie może zaakceptować jakiejś kombinacji, użyj Assume.assumeThatimportu statycznego, aby odfiltrować nieprawidłowe kombinacje (np. gdy chcesz sprawdzić zachowanie metody dla niepustych ciągów znaków, jedną z pierwszych linii będzie „załóż, że nie jest pusta”

Jak napisano wcześniej - nie ma sensu testować każdej możliwej kombinacji każdej metody (rozbija zestawy testowe, wyobraź sobie testowanie metody z 5 parametrami, z których każdy ma tylko 5 możliwych wartości: 5 ** 5 -> ponad 3000 testów !), ale w przypadku metod krytycznych dla misji (takich jak metody API) zachęcam do tego, aby być po bezpiecznej stronie ...

Ogólny przykład:

• Metody z argumentami łańcuchowymi. Użyj sparametryzowanych testów do przetestowania różnych danych wejściowych i ich oczekiwanych wyników. O wiele bardziej praktyczne jest posiadanie listy par (dane wejściowe, oczekiwane) niż pisanie TC dla każdej pary.

• Zastosuj ten sam scenariusz do różnych argumentów. Mamy scenariusz, który działa z Animalobiektu i mają wiele podklas, takich jak Dog, Cat, Bird. Utwórz listę dostępnych zwierząt i przetestuj na nich scenariusz.

Beton do usługi internetowej:

• Z powyższego przykładu argumentów łańcuchowych. Sprawdź, co dzieje się z różnymi argumentami tego samego typu, ale o różnych wartościach.

Testy sparametryzowane dobrze sprawdzają się w testowaniu funkcji / funkcji, które mają proste dane wejściowe, gdy chcesz przetestować różne dane wejściowe.

Nie działają dobrze do testowania różnych funkcji i skomplikowanych danych wejściowych. Nie należy ich używać jako struktury wygodnej do pisania mniej kodu.

Jednym z przypadków, w których korzystam z wielu sparametryzowanych testów w sposób TDD, jest pisanie parserów - mogę zacząć od listy, jeśli dane wejściowe i oczekiwane dane wyjściowe, a następnie napisać kod, aby przekazać wszystkie przypadki testowe.

Ale widziałem kilka okropności sparametryzowanych testów. Nie, Virginia, twój zestaw testów nie powinien potrzebować własnych testów jednostkowych.