#3 Antywzorce w testowaniu oprogramowania: Korzystanie z niewłaściwego rodzaju testów

17 października 2018 | Trochę teorii, Uczymy się!

Wszyscy wiemy, jak z grubsza wygląda piramida testów: na dole jednostkowe, potem integracyjne, a szczytu akceptacyjne. Oznacza to po prostu tyle, że im wyżej w piramidzie, tym testów powinno być mniej… Ale mniej, to znaczy ile?

Wiem już, dlaczego nie powinniśmy przeginać z testami jednostkowymi oraz dlaczego same testy integracyjne to raczej średni pomysł. No i okej, ale co z pozostałymi rodzajami? Jak już wiemy – powinno być ich mniej. Ale dziś odpowiemy sobie na pytanie co oznacza owo mistyczne „mniej”.

Zacznijmy od tego, że piramida wcale aż tak nie ułatwia zadania, bo jest ona tylko sugestią, wcale nie jest powiedziane, że dla naszej aplikacji proporcjonalny spadek liczby testów w zależności od ich rodzaju wcale nie będzie przynosił największej wartości.

Wyobraźmy sobie, że aplikacja którą testujemy opiera się o wiersz poleceń – chyba każdemu choć raz zdarzyło się z takiej korzystać (przykładem może być przydatne w testowaniu dostępności Pa11y, co przypomina mi, że jeszcze nie napisałam obiecanego tutaj artykułu na temat tego narzędzia :)). Nasza aplikacja czyta jeden specjalny format pliku (np. CSV) i eksportuje w inny format (powiedzmy XML) po wykonaniu pewnych transformacji. Dodatkowo aplikacja jest samodzielna nie komunikuje się z żadnym innym systemem i nie korzysta z sieci. Przekształcenia formatów są złożonymi procesami matematycznymi, które są krytyczne dla prawidłowego funkcjonowania aplikacji (powinny być zawsze poprawne, nawet jeśli są wolne).

Czego potrzebujemy? Na pewno dużej liczby unit testów, które sprawdzą zachodzące procesy oraz kilka testy integracyjnych sprawdzających odczytywanie plików CSV i zapisywanie plików JSON przez naszą aplikację. Nie ma GUI, zatem nie ma testów GUI.
W takim wypadku testy jednostkowe dominują, a kształt nasza piramida straci swój pierwotny kształt.

A co jeśli testujemy aplikację, która prawie pozbawiona jest logiki biznesowej, za to integruje się z mnóstwem systemów? Tak jest na przykład w przypadku bramki do płatności on-line, jedynie przetwarzającej informacje o płatnościach. Informacje przechowywane są w zewnętrznej bazie danych, a sama aplikacja komunikuje się zewnętrznymi dostawcami płatności (np. PayPal) oraz przesyła informacje do zewnętrznego systemu fakturującego. Co wtedy? Ponownie testy GUI są zbędne, zaś znikoma logika biznesowa podpowiada, że i testów jednostkowych będzie odpowiednio mniej. W tym wypadku na pierwszy plan wyjdą testy integracyjne, co możemy wywnioskować już z ogromnej liczby połączeń.

A czy zdarzy się, że to testy GUI zdominują naszą “piramidę” testów? Może tak być w przypadku aplikacji z wyjątkowo rozbudowanym GUI, na przykład kreatora graficznego on-line. Aby użytkownikowi ułatwić zadanie tworzenia grafiki, strona działa w bardzo przyjazny sposób: umożliwia przeciąganie i upuszczanie komponentów na stronie, zmianę ich rozmiaru, edycję ich właściwości oraz zmianę kolorów i wyglądu. Ponownie, testów jednostkowych będzie niewiele, co spowodowane jest ograniczoną logiką biznesową. Może kilka testów integracyjnych. No i zdecydowanie cały arsenał testów GUI.

Jak widać, nie zawsze ilość testów danego rodzaju da się określić tak łatwo, jak może sugerować to popularna piramida testów. Za każdym razem powinniśmy kierować się więc nie jej szablonem, a tym, co najlepsze dla naszej aplikacji i tak dobierać liczbę przypadków testowych na danym poziomie, by zapewnić jak największą jakość.

Wszystkie opisane w artykule przykłady pochodzą ze strony Codepipes Blog.

Najnowsze wpisy

Quality Excites 2019

Wczoraj zakończyła się 8. edycja konferencji Quality Excites, w ramach której miałam okazję prowadzić panel dyskusyjny. Wnioski z dyskusji umieszczę tutaj wkrótce, a dziś zachęcam Was do przeczytania podsumowania moich wrażeń z tego wydarzenia.

test:fest 2019 – podsumowanie

Czas na recenzję Test:fest – bez wątpienia jednego z bardziej rozpoznawalnych testerskich wydarzeń w Polsce.

Quality Meetup #19 – podsumowanie

Już ponad miesiąc minął, odkąd wystąpiłam na Quality Meetup ze swoją prezentacją poświęconą błędom poznawczym. A jeszcze więcej od ostatniego wpisu na blogu. Czas najwyższy więc na dobre wyjść ze snu zimowego i zacząć nadrabiać.

Pin It on Pinterest

Podoba Ci się wpis?

Podziel się ze znajomymi!