Dowiedz się, jak łączyć różne typy testów w racjonalną strategię, która pasuje do Twojego projektu.
Witamy z powrotem W poprzednim artykule przedstawiliśmy wiele informacji o tym, jak podchodzić do różnych typów testów i co one obejmują, a także wyjaśniliśmy definicje typów testów. Pamiętasz ten meme? Być może zastanawiasz się, jak wszystkie omówione typy testów mogą ze sobą współpracować.
W następnym kroku dowiesz się dokładnie, jak to zrobić. Z tego artykułu dowiesz się, jak łączyć te typy testów w racjonalne strategie i wybierać te, które pasują do Twojego projektu.
Aby lepiej zrozumieć znaczenie strategii, możesz porównać je z różnymi kształtami. Oto lista strategii z odpowiednimi rozmiarami i zakresem rozwoju.
Przyjrzyjmy się bliżej strategiom i poznajmy znaczenie ich nazw.
Określ cele testów: czego chcesz osiągnąć za pomocą tych testów?
Zanim zaczniesz tworzyć dobrą strategię, określ cel testowania. Kiedy uważasz, że aplikacja została odpowiednio przetestowana?
Osiągnięcie wysokiego pokrycia testami jest często uważane za ostateczny cel testów dla programistów. Czy jednak zawsze jest to najlepsze podejście? Przy podejmowaniu decyzji o strategii testowania warto wziąć pod uwagę jeszcze jeden ważny czynnik – potrzeby użytkowników.
Jako deweloper korzystasz też z wielu innych aplikacji i urządzeń. W tym sensie jesteś użytkownikiem, który oczekuje, że wszystkie te systemy będą „działać”. Ty z kolei ufasz, że niezliczone rzesze deweloperów dołożą wszelkich starań, aby ich aplikacje i urządzenia działały. Jako deweloper musisz też dbać o to, aby użytkownicy Ci ufali. Dlatego Twoim pierwszym celem powinno być zawsze dostarczenie działającego oprogramowania i obsługa użytkowników. Dotyczy to również testów, które piszesz, aby zapewnić jakość aplikacji. Kent C. Dodds bardzo dobrze podsumowuje to w artykule Testowanie statyczne, testowanie jednostkowe, testowanie integracyjne i testowanie E2E aplikacji front-end:
Im bardziej testy przypominają sposób używania oprogramowania, tym większą dają pewność.
przez Kent C. Dodds
Kent określa to jako zdobywanie pewności siebie w testach. Im bardziej dopasujesz typ testów do użytkowników, tym bardziej możesz ufać, że wyniki testów będą wiarygodne. Innymi słowy, im wyżej wspinasz się po drabinie, tym większa jest Twoja pewność siebie. Ale czy wiesz, czym jest piramida?
Określanie strategii testowania: jak wybrać strategię testowania
Najpierw określ, które części wymagań musisz sprawdzić, aby upewnić się, że są spełnione. Dowiedz się, których typów testów używać i na jakim poziomie szczegółowości, aby uzyskać jak największą pewność przy zachowaniu efektywnej struktury kosztów. Wielu deweloperów podchodzi do tego tematu, używając analogii. Oto najpopularniejsze z nich, zaczynając od dobrze znanego klasyka.
Klasyka: piramida testów
Gdy zaczniesz szukać strategii testowania, pierwszą analogią, na którą prawdopodobnie trafisz, będzie piramida automatyzacji testów. Mike Cohn przedstawił tę koncepcję w książce „Succeeding with Agile” (Świetły sukces dzięki metodyce zwinnej). Później Martin Fowler rozwinął tę koncepcję w artykule Praktyczna Piramida Testów. Piramidę możesz wizualizować w ten sposób:
Jak widać na tym rysunku, piramida testów składa się z 3 poziomów:
Jednostka. Te testy znajdują się na najniższym poziomie piramidy, ponieważ są szybkie w wykonywaniu i łatwe w utrzymywaniu. Są one izolowane i kierowane na najmniejsze jednostki testowe. Przykładowy test jednostkowy dla bardzo małego produktu.
Integracja. Te testy znajdują się w środku piramidy, ponieważ mają akceptowalną szybkość wykonywania, ale przybliżają Cię do użytkownika bardziej niż testy jednostkowe. Przykładem testu integracji jest test interfejsu API. Do tego typu możesz też zaklasyfikować testy komponentów.
Testy E2E (nazywane też testami interfejsu użytkownika). Te testy symulują prawdziwego użytkownika i jego interakcje. Takie testy wymagają więcej czasu na wykonanie, a co za tym idzie, są droższe. Znajdują się na szczycie piramidy.
Poziom ufności a zasoby
Jak już wspomnieliśmy, kolejność warstw nie jest przypadkowa. Pokazują one priorytety i odpowiednie koszty. Dzięki temu możesz dokładnie określić, ile testów należy napisać dla każdej warstwy. Te informacje znajdziesz już w definicji typów testów.
Testy E2E są najbardziej zbliżone do użytkowników, dlatego zapewniają największe poczucie pewności, że aplikacja działa zgodnie z oczekiwaniami. Wymagają jednak pełnego zestawu aplikacji i symulowanego użytkownika, dlatego są też potencjalnie najdroższe. Zatem wiarygodność jest w bezpośredniej konkurencji z zasobami potrzebnymi do wykonania testów.
Piramida rozwiązuje ten problem, ponieważ pozwala skupić się bardziej na testach jednostkowych i ściśle ustalać priorytety przypadków objętych testami E2E. Na przykład najważniejsze ścieżki użytkowników lub miejsca najbardziej narażone na błędy. Jak podkreśla Martin Fowler, 2 najważniejsze punkty w piramidzie Cohn to:
- pisać testy o różnym stopniu szczegółowości,
- Im wyższy poziom, tym mniej testów.
Kiełek ewoluował! Adaptacje testowych piramid
Przez kilka lat trwały dyskusje na temat piramidy. Piramida wydaje się zbytnio upraszczać strategie testowania, pomija wiele typów testów i nie pasuje już do wszystkich projektów w rzeczywistych warunkach. Może to wprowadzać w błąd. Czy piramida straciła swój kształt? Guillermo Rauch ma na ten temat opinię:
pisać testy, Nie za dużo. Głównie integracja.
Guillermo Rauch
To jedno z najczęściej cytowanych zdań na ten temat, więc przyjrzyjmy się mu bliżej:
- „Write tests” (Pisanie testów). Nie tylko dlatego, że buduje zaufanie, ale też dlatego, że oszczędza czas na konserwację.
- „Niezbyt wiele”. 100% pokrycia nie zawsze jest dobre, ponieważ testy nie są wtedy priorytetyzowane, a konserwacja jest bardzo czasochłonna.
- „Większość integracji”. Ponownie kładziemy nacisk na testy integracji: mają one największą wartość biznesową, ponieważ zapewniają wysoki poziom ufności na co dzień przy zachowaniu rozsądnego czasu wykonania.
W związku z tym warto ponownie zastanowić się nad piramidą testów i skupić się na testach integracji. W ciągu ostatnich kilku lat zaproponowano wiele adaptacji, więc przyjrzyjmy się najpopularniejszym z nich.
Diament testowy
Pierwsza modyfikacja polega na usunięciu nadmiernego nacisku na testowanie jednostkowe, jak widać na piramidzie testów. Wyobraź sobie, że testy jednostkowe osiągnęły 100% pokrycia. Jednak przy następnej refaktoryzacji trzeba będzie zaktualizować wiele z tych testów jednostkowych, więc możesz chcieć je pominąć. W związku z tym ulegają one erozji.
W efekcie, wraz z większym naciskiem na testowanie integracji, może pojawić się taka struktura:
Piramida zmienia się w diament. Widać 3 poprzednie warstwy, ale w innym rozmiarze, a warstwa jednostki została wycięty:
- Jednostka. Napisać testy jednostkowe w sposób zdefiniowany wcześniej. Jednak ponieważ mają one tendencję do erozji, należy je traktować jako priorytety i stosować tylko w najbardziej krytycznych przypadkach.
- Integracja. Testy integracji, które znasz, testują kombinację poszczególnych jednostek.
- E2E. Ta warstwa obsługuje testy UI w sposób podobny do piramidy testów. Pamiętaj, aby pisać testy E2E tylko w przypadku najważniejszych przypadków testowych.
Testowanie plastra miodu
Istnieje też inna adaptacja, wprowadzona przez Spotify, która jest podobna do diamentu testowego, ale bardziej dostosowana do systemów oprogramowania opartych na mikrousługach. Siatka testów to kolejna wizualna analogia do szczegółowości, zakresu i liczby testów, które należy napisać dla systemu opartego na mikrousługach. Ze względu na ich niewielki rozmiar największa złożoność mikroserwisu nie dotyczy samej usługi, ale sposobu, w jaki wchodzi ona w interakcje z innymi usługami. Dlatego strategia testowania mikrousługi powinna koncentrować się przede wszystkim na testach integracji.
Kształt przypomina nam plaster miodu, stąd nazwa. Składa się z tych warstw:
- Testy zintegrowane. Artykuł Spotify zawiera cytat z artykułu J. B. Rainsberger tak definiuje tę warstwę: „Test, który zakończy się powodzeniem lub niepowodzeniem w zależności od poprawności innego systemu”. Takie testy mają zewnętrzne zależności, które należy wziąć pod uwagę. Z drugiej strony Twój system może być zależnością, która zakłóca działanie innych systemów. Podobnie jak w przypadku testów E2E w innych analogiach, należy stosować je ostrożnie, tylko w najbardziej istotnych przypadkach.
- testy integracyjne. Podobnie jak w przypadku innych dostosowań, powinieneś skupić się na tej warstwie. Zawiera testy, które sprawdzają poprawność usługi w bardziej odizolowany sposób, ale nadal w połączeniu z innymi usługami. Oznacza to, że testy będą obejmować też inne systemy i skupiać się na punktach interakcji, np. za pomocą testów interfejsu API.
- Testy dotyczące szczegółów implementacji. Te testy przypominają testy jednostkowe, które koncentrują się na częściach kodu, które są naturalnie izolowane i mają własną wewnętrzną złożoność.
Aby dowiedzieć się więcej o tej strategii testowania, przeczytaj post, w którym porównujemy piramidę testów z strukturą plastra miodu, autorstwa Martina Fowlera, oraz pierwotny artykuł Spotify.
Testowanie trofeum
Już teraz możesz zauważyć powtarzające się testy integracji. Inny typ testów, o którym wspominaliśmy w poprzednim artykule, nie jest testem teoretycznym, ale i tak jest ważnym aspektem, który należy uwzględnić w strategii testowania. Analiza statyczna nie jest uwzględniona w piramidzie testów ani w większości dotychczas stosowanych adaptacji. Dostępna jest adaptacja trofeum za testowanie, która uwzględnia analizę statyczną, a jednocześnie koncentruje się na testach integracji. Puchar testowy powstał na podstawie wcześniejszego cytatu Guillermo Raucha i został opracowany przez Kenta C. Dodds:
Puchar testów to analogia przedstawiająca szczegółowość testów w nieco inny sposób. Składa się z 4 warstw:
- Analiza statyczna. Odgrywa ona kluczową rolę w tej analogii i pozwala wykrywać literówki, błędy stylistyczne i inne błędy, po prostu wykonując opisane już kroki debugowania.
- Testy jednostkowe. Dzięki nim możesz mieć pewność, że najmniejsza jednostka jest odpowiednio testowana, ale trofeum za testowanie nie będzie podkreślać tych informacji w takim samym stopniu jak piramida testów.
- Integracja. Jest to główny cel, ponieważ zapewnia równowagę między kosztami a większym poziomem ufności w najlepszy sposób, podobnie jak w przypadku innych dostosowań.
- testy UI. Obejmują one testy E2E i testy wizualne, które są najwyżej w hierarchii testów, podobnie jak ich rola w piramidzie testów.
Więcej informacji o trofeowaniu testów znajdziesz w poście na blogu Kenta C. Dodds na ten temat.
Kilka metod skupionych na interfejsie użytkownika
To wszystko brzmi nieźle, ale niezależnie od tego, czy nazywasz swoją strategię „piramidą”, „plastrem miodu” czy „diamentową”, zawsze czegoś brakuje. Automatyzacja testów jest przydatna, ale należy pamiętać, że ręczne testowanie jest nadal niezbędne. Automatyczne testowanie powinno ułatwiać wykonywanie rutynowych zadań i uwalniać inżynierów ds. zapewnienia jakości, aby mogli skupić się na kluczowych obszarach. Automatyzacja nie powinna zastępować testów ręcznych, ale je uzupełniać. Czy istnieje sposób na zintegrowanie testów ręcznych z automatyzacją, aby uzyskać optymalne wyniki?
Testowanie rożka na lody i kraba
Istnieją 2 modyfikacje piramidy testów, które koncentrują się bardziej na testowaniu interfejsu użytkownika. Oba mają zaletę w postaci wysokiej pewności, ale są oczywiście droższe ze względu na wolniejsze wykonywanie testów.
Pierwszy, testowy wafel, wygląda jak odwrócona piramida. Bez etapu ręcznego testowania jest ona też nazywana pizzą testową.
Lody w rożku to testy manualne lub testy UI, a najmniej testy jednostkowe. Często powstaje w projektach, w których programiści zaczęli pracę z niewielką liczbą pomysłów na strategię testowania. Kod ice jest uważany za nieodpowiedni sposób działania. Jest kosztowny pod względem zasobów i pracy ręcznej.
Test kraba jest podobny do testu rożka, ale z większym naciskiem na testowanie end-to-end i wizualne:
Ta strategia testowania obejmuje jeszcze jeden aspekt: sprawdzanie, czy aplikacja działa i czy dobrze wygląda. Krab testowy podkreśla znaczenie testów wizualnych, które zostały opisane w poprzednim artykule. Testowanie integracji, podzielone na testowanie komponentów i testowanie interfejsu API, schodzi na dalszy plan, a testowanie jednostkowe odgrywa tu jeszcze mniej istotną rolę. Więcej informacji o tej strategii testowania znajdziesz w tym artykule o krabie testów.
Te dwie strategie testowania są droższe, ale mają swoje zastosowanie: na przykład w mniejszych projektach, w których przypadku potrzeba mniej testów lub mniejszej złożoności. W takim przypadku pełna strategia testowania skupiająca się na testach integracji może być zbyt skomplikowana.
Chociaż te dwie strategie testowania są droższe, mają swoje zastosowanie, np. w mniejszych projektach, które wymagają mniejszej liczby testów i nie muszą być bardzo złożone. W takim przypadku pełna strategia testowania skupiona na testach integracji może być niepotrzebnie skomplikowana.
Praktyczne porady: zaplanujmy strategię
Poznaliśmy już najpopularniejsze strategie testowania. Zaczęliście od klasycznej piramidy testów i poznaliście jej wiele adaptacji. Teraz musisz je ocenić pod kątem swojego produktu i zdecydować, która z nich będzie najlepsza do Twojego projektu. Odpowiedź na to pytanie powinna zaczynać się od ulubionego zwrotu wszystkich „To zależy”. Nie oznacza to jednak, że nie są one dokładne.
Wybór najbardziej odpowiedniej strategii testowania spośród opisanych (a nawet tych niewymienionych) zależy od aplikacji. Powinna ona pasować do Twojej architektury i Twoich wymagań, a także do potrzeb użytkowników. Te wszystkie elementy mogą się różnić w zależności od aplikacji. To zupełnie normalne. Pamiętaj, że najważniejszym celem jest zaspokajanie potrzeb użytkowników, a nie trzymanie się ściśle definicji podręcznikowej.
Testy w rzeczywistych warunkach często trudno jest oddzielić i zdefiniować pojedynczo. Nawet sam Martin Fowler podkreśla pozytywny aspekt różnych definicji, na przykład w przypadku testów jednostkowych. Jak słusznie zauważa Justin Searls w tweetu:
[…] pisz testy, które określają wyraźne granice, działają szybko i niezawodnie oraz nie przechodzą tylko z powodów, które mają znaczenie.
Justin Searls
Skup się na testach, które zgłaszają rzeczywiste błędy, z którymi mogą się spotkać użytkownicy, i nie rozpraszaj się innymi celami. Testy powinny być zaprojektowane tak, aby przynosiły korzyści użytkownikowi, a nie tylko zapewniać 100% zasięgu lub umożliwiać prowadzenie dyskusji na temat tego, jaki odsetek testów danego typu należy napisać.
Skup się na testach, które zgłaszają błędy występujące w rzeczywistych warunkach, i nie rozpraszaj się innymi celami. Testy powinny być zaprojektowane z myślą o korzyściach dla użytkownika, a nie tylko zapewniać 100% zasięgu lub wywoływać debaty na temat tego, jaki procent kodu danego typu testów powinieneś napisać.