Dowiedz się, jak łączyć różne typy testowania w ramach rozsądnej strategii, która pasuje do Twojego projektu.
Witamy z powrotem. Ostatni artykuł zawierał wiele podstawowych informacji o różnych rodzajach testów i ich zawartości, a także wyjaśniał ich definicje. Pamiętasz ten mały mem? Być może zastanawiasz się, jak te wszystkie rodzaje testów, które poznaliśmy, mogą ze sobą współdziałać.
Teraz się tego dokładnie dowiesz. Ten artykuł zawiera informacje o tym, jak łączyć te typy testowania w rozsądne strategie i jak wybrać taką, która pasuje do Twojego projektu.
Możesz porównywać strategie na podstawie różnych kształtów, aby lepiej zrozumieć ich znaczenie. Oto lista strategii z odpowiednimi rozmiarami i zakresami zaprogramowania.
Przyjrzyjmy się bliżej strategiom i sprawdźmy, co kryje się za ich nazwami.
Określenie celów testowania: co chcesz osiągnąć dzięki tym testom?
Zanim zaczniesz tworzyć dobrą strategię, ustal cel testowania. Kiedy uważasz, że Twoja aplikacja została wystarczająco przetestowana?
Uzyskanie dużego zasięgu testów jest często uważane przez deweloperów za główny cel testowania. Ale czy zawsze jest to najlepsze podejście? Przy podejmowaniu decyzji o strategii testowania trzeba rozważyć inny czynnik decydujący o potrzebach użytkowników.
Jako programista korzystasz też z wielu innych aplikacji i urządzeń. W tym sensie to Ty jesteś użytkownikiem, który polega na tych wszystkich systemach, aby „po prostu działać”. W związku z tym niezliczonych programistów, którzy dokładają wszelkich starań, aby ich aplikacje i urządzenia działały prawidłowo. Jako deweloper musisz również zaspokoić to zaufanie. Dlatego Twoim pierwszym celem powinno być zawsze dostarczenie działającego oprogramowania i obsługa użytkowników. Dotyczy to też testów, które piszesz, aby zapewnić odpowiednią jakość aplikacji. Kent C. Dodds bardzo dobrze podsumowuje ten post w poście Static vs Unit vs Integration vs E2E Testing for Frontend Apps (Testowanie statyczne vs. Unit vs Integration vs E2E Testing for Frontend Apps).
Im bardziej testy przypominają sposób korzystania z oprogramowania, tym większą wiarygodność możesz uzyskać.
autor: Kent C. Dodds
Kent twierdzi, że to nabieranie pewności siebie w testach. Im bliżej użytkowników wybierzesz odpowiedni typ testowania, tym bardziej będziesz mieć pewność, że testy wykażą wiarygodność wyników. Innymi słowy, im wyżej się wejdziesz na piramidę, tym bardziej zyskasz pewność siebie. Ale zaraz, czym jest piramida?
Określenie strategii testowania: jak wybrać strategię testowania
Najpierw ustal, które wymagania musisz sprawdzić, aby mieć pewność, że je spełniają. Dowiedz się, jakich typów testów użyć i jaki poziom szczegółowości pozwoli Ci uzyskać największą wiarygodność przy zachowaniu opłacalnej struktury kosztów. Wielu programistów podchodzi do tego tematu, stosując analogie. Oto najpopularniejsze, zaczynając od dobrze znanego klasyki.
Klasyka: piramida testowa
Gdy tylko zaczniesz szukać strategii testowych, prawdopodobnie natkniesz się na piramidę automatyzacji testów jako pierwszą analogię. Mike Cohn przedstawił tę koncepcję w swojej książce „Sukceeding with Agile”. Później Martin Fowler rozwinął tę koncepcję w swoim artykule Praktyczna piramida testowa. Piramidę możesz przedstawić wizualnie w następujący sposób:
Jak pokazano na tym rysunku, piramida testowa składa się z trzech warstw:
Unit (Jednostka). Te testy znajdują się w warstwie podstawowej piramidy, ponieważ są szybkie do wykonania i proste w obsłudze. Są one izolowane i kierowane na najmniejsze jednostki testowe. Zobacz na przykład typowy test jednostkowy bardzo małego produktu.
Integracja Te testy są w środku piramidy, ponieważ ich szybkość wykonywania jest akceptowalna, ale przybliżają Cię do użytkownika niż testy jednostkowe. Przykładem testu integracji jest test interfejsu API. Do tego typu możesz również klasyfikować testy komponentów.
Testy E2E (nazywane też testami interfejsu użytkownika). Te testy symulują autentycznego użytkownika i jego interakcję. Wykonanie takich testów wymaga więcej czasu i dlatego są droższe. Są na szczycie piramidy.
Pewność a zasoby
Jak już wspomnieliśmy wcześniej, kolejność warstw nie jest przypadkowa. Wskazują one priorytety i odpowiadające im koszty. Dzięki temu dowiesz się, ile testów należy utworzyć w przypadku każdej warstwy. Ta zasada była już widoczna w definicji typów testów.
Testy E2E są najbliżej użytkowników, więc dają największą pewność, że aplikacja działa zgodnie z oczekiwaniami. Wymagają one jednak pełnego stosu aplikacji i symulowanego użytkownika, dlatego są potencjalnie najbardziej kosztowne. Można więc stwierdzić, że istnieje bezpośrednia rywalizacja z zasobami potrzebnymi do przeprowadzenia testów.
Piramida próbuje rozwiązać ten problem, skupiając się w większym stopniu na testach jednostkowych i nadrzędności w przypadkach objętych testami E2E. Mogą to być na przykład najważniejsze ścieżki użytkowników lub miejsca najbardziej narażone na awarie. Jak podkreśla Martin Fowler, dwa najważniejsze punkty piramidy Cohna to:
- Pisz testy o różnej szczegółowości.
- Im wyższy poziom, tym mniej testów trzeba przeprowadzić.
Piramida ewoluowała! Adaptacje piramid testowych
Od kilku lat toczy się wokół piramidy. Wydaje się, że piramida zbyt upraszcza strategie testowania, pomija wiele rodzajów testowania i nie pasuje już do niektórych projektów ze świata rzeczywistego. Z tego powodu może wprowadzać w błąd. Czy piramida odpadła? Guillermo Rauch ma opinię na ten temat:
Pisz testy. Niezbyt wiele. Głównie integracja.
Guillermo Rauch
Jest to jeden z najczęściej cytowanych cytatów na ten temat, więc przeanalizujmy go:
- „Napisz testy”. Nie tylko dlatego, że wzbudza zaufanie, ale też pozwala zaoszczędzić czas potrzebny na obsługę.
- „Nie za dużo”. 100% pokrycia nie zawsze jest dobre, ponieważ wtedy testowanie nie ma priorytetu i wymaga dużych nakładów pracy.
- „Głównie integracja”. Tutaj również nacisk kładzie się na testy integracji: mają one największą wartość biznesową, ponieważ zapewniają codzienny wysoki poziom pewności w przypadku rozsądnego czasu wykonania.
W ten sposób możesz zastanowić się nad piramidą testowania i skupić się na testowaniu integracji. W ciągu ostatnich kilku lat pojawiło się wiele dostosowań. Przyjrzyjmy się najczęstszym z nich.
Diament testowy
Pierwsza adaptacja eliminuje zbyt duży nacisk na testowanie jednostkowe, jak widać w piramidzie testów. Załóżmy, że w testach jednostkowych udało Ci się osiągnąć 100% pokrycia. Jednak przy następnej refaktoryzacji trzeba będzie zaktualizować wiele z tych testów jednostkowych i może okazać się, że warto je pominąć. Więc ulegają erozji.
W rezultacie, przy większym skupieniu na testowaniu integracji, może pojawić się taki kształt:
Piramida zmienia się w diament. Widać 3 poprzednie warstwy, ale w innym rozmiarze, a warstwa jednostkowa została wycięta:
- Unit (Jednostka). Napisz testy jednostkowe w takiej postaci, w jakiej zostały zdefiniowane wcześniej. Jednak z reguły się tracą, dlatego uwzględniają one priorytetowo tylko najważniejsze przypadki.
- Integracja Znane Ci testy integracji, czyli testy kombinacji pojedynczych jednostek.
- E2E: Ta warstwa obsługuje testy interfejsu podobne do piramidy testowej. Testy E2E należy pisać tylko w najważniejszych przypadkach.
Testowanie plastra miodu
Spotify wprowadziła też inną adaptację, która jest podobna do testowego diamentu, ale bardziej wyspecjalona w przypadku systemów oprogramowania opartych na mikroserwisach. Testowanie honeycomb to kolejna wizualna analogia dotycząca szczegółowości, zakresu i liczby testów do zapisania na potrzeby systemu oprogramowania opartego na mikroserwisach. Ze względu na ich niewielki rozmiar najważniejsza złożoność mikroserwisu dotyczy nie samej usługi, lecz sposobu jej interakcji z innymi. Z tego względu strategia testowania mikroserwisu powinna koncentrować się głównie na testach integracji.
Ten kształt przypomina plaster miodu, a tym samym jego nazwę. Zawiera te warstwy:
- Zintegrowane testy. Artykuł przygotowany przez Spotify korzysta z cytatu J. B. Rainsberger, by zdefiniować tę warstwę: „test, który zaliczy zaliczenie lub niepowodzenie w zależności od poprawności innego systemu”. Takie testy mają zewnętrzne zależności, które trzeba wziąć pod uwagę. W przeciwnym razie Twój system może być zależność, która narusza inne systemy. Podobnie jak w przypadku testów E2E w innych analogii, przeprowadzaj te testy z rozwagą i tylko w najważniejszych przypadkach.
- Testy integracji. Skup się na tej warstwie – podobnie jak w przypadku innych adaptacji. Zawiera on testy, które w bardziej izolowany sposób sprawdzają poprawność Twojej usługi, ale wciąż w połączeniu z innymi usługami. Oznacza to, że testy obejmują również inne systemy i skoncentrują się na punktach interakcji, np. z wykorzystaniem testów interfejsu API.
- Testowanie szczegółów implementacji. Testy te przypominają testy jednostkowe – 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 posta z porównaniem piramidy testowej z „plasterem miodu” autorstwa Martina Fowlera oraz oryginalnego artykułu ze Spotify.
Puchar testowy
Widać już, że testy integracji powtarzają się. Inny rodzaj treści, o których mowa w poprzednim artykule, nie jest jednak testem teoretycznym, ale jest ważnym aspektem, o którym warto pamiętać w strategii testowania. Analizy statycznej brakuje w piramidzie testowej i w większości dotychczasowych adaptacji. Występuje tu adaptacja trofeum, która uwzględnia analizę statyczną, a jednocześnie koncentruje się na testach integracji. Trofeum testowe pochodzi z wcześniejszego cytatu Guillermo Raucha i zostało opracowane przez Kenta C. Dodds:
Trofeum testów to analogia obrazująca szczegółowość testów w nieco inny sposób. Ma 4 warstwy:
- Analiza statyczna. Odgrywa on kluczową rolę w tej analogii i umożliwia wychwytywanie literówek, błędów stylu i innych błędów dzięki wykonaniu czynności debugowania, które zostały już przedstawione.
- Testy jednostkowe. Dzięki nim najmniejsza jednostka zostanie odpowiednio przetestowana, ale trofeum nie wyróżni ich w takim stopniu jak piramida testowa.
- Integracja Na tym się skupiamy, ponieważ zapewnia ona równowagę między kosztami i większą pewnością siebie, podobnie jak w przypadku innych dostosowań.
- Testy interfejsu. W tym E2E i testy wizualne są na pierwszym miejscu, podobnie jak w piramidzie testów.
Aby dowiedzieć się więcej o trofeum testowym, przeczytaj posta na blogu autorstwa Kenta C. na ten temat.
Kilka rozwiązań skoncentrowanych na UI
Wszystko jest w porządku, ale bez względu na to, jak nazwiesz swoją strategię, „piramida”, „plaster miodu” czy „diament”, zawsze czegoś brakuje. Automatyzacja testów jest cenna, ale trzeba pamiętać, że nadal niezbędne są testy ręczne. Zautomatyzowane testy powinny uprościć rutynowe zadania i uwolnić inżynierów ds. kontroli jakości do skupienia się na kluczowych obszarach. Zamiast zastępować testy ręczne, powinna ją uzupełnić automatyzacja. Czy można zintegrować testy ręczne z automatyzacją, aby uzyskać optymalne wyniki?
Testowanie rożka lodowego i krabów
Istnieją dwie adaptacje piramidy testowania, które koncentrują się bardziej na metodach testowania zorientowanych na interfejs użytkownika. Obie metody mają wysoką pewność, ale są z natury droższe ze względu na wolniejsze wykonywanie testu.
Pierwszy, stożek lodowy, wygląda jak odwrócona piramida. Bez konieczności ręcznego testowania jest to pizza testowa.
Rożek lodowy w większym stopniu skupia się na testach ręcznych i UI, a najmniejszy jest na testowaniu jednostkowym. Często sprawdza się w projektach, w których deweloperzy rozpoczynali pracę, mając tylko kilka uwag na temat strategii testowania. Kod lodowy jest uważany za niezgodną z wzorcem i słusznie. Jego wykorzystanie jest kosztowne pod względem zasobów i pracy ręcznej.
Krab testowy jest podobny do testowego stożka lodowego, ale z większym naciskiem na E2E i testy wizualne:
Ta strategia testowania obejmuje jeszcze jeden aspekt: pozwala sprawdzić, czy aplikacja działa i wygląda dobrze. Krab testowy podkreśla znaczenie testów wizualnych, które opisaliśmy w poprzednim artykule. Testowanie integracji, podzielone na testowanie komponentów i interfejsów API, odbywa się w tle, a testowanie jednostkowe odgrywa tu jeszcze większą rolę. Więcej informacji na temat tej strategii testowania znajdziesz w tym artykule o krabach testowych.
Te 2 strategie testowania są bardziej kosztowne, ale np. w mniejszych projektach, w których wymagana jest mniejsza liczba testów lub w przypadku mniej złożoności. W takim przypadku wszechstronna strategia testowania skoncentrowana na testowaniu integracji może być zbyt trafna.
Te 2 strategie testowania są bardziej kosztowne, ale sprawdzają się np. w mniejszych projektach, które wymagają mniejszej liczby testów i nie wymagają dużej złożoności. W takim przypadku strategia testowania na pełną skalę, która koncentruje się na testowaniu integracji, może być niepotrzebnie złożona.
Porady praktyczne: opracujmy strategię
Znasz już najbardziej typowe strategie testowania. Zaczęliście od klasycznej – piramidy testowej – i poznaliście wiele jej adaptacji. Teraz musisz ocenić je pod kątem swojej usługi i zdecydować, które z nich najlepiej sprawdzą się w przypadku Twojego projektu. Odpowiedź na to pytanie powinna się zaczynać od „To zależy”. To nie oznacza jednak, że jest mniej dokładna.
Wybór najodpowiedniejszej strategii testowania spośród opisanych, a nawet tych, które nie zostały uwzględnione, zależy od Twojej aplikacji. Powinna ona uwzględniać Twoją architekturę, Twoje wymagania, a także użytkowników i ich wymagania. Wszystko to może się różnić w zależności od aplikacji. To zupełnie normalne. Pamiętaj, że najważniejszym celem jest słuszność użytkownikom, a nie definicja z podręcznika.
Zwykle trudno jest oddzielić i zdefiniować testy w praktyce. Nawet Martin Fowler podkreśla pozytywny aspekt różnych definicji, np. w przypadku testów jednostkowych. Jak stwierdził Justin Searls w swoim tweetie:
[...] pisz szczegółowe testy, które wyznaczają wyraźne granice, są szybkie i niezawodne oraz kończą się niepowodzeniem tylko z ważnych powodów.
autor: Justin Searls
Skoncentruj się na testach, które pokazują rzeczywiste błędy, na które mogą natrafić użytkownicy, i które nie odwracają uwagi od celu. Testy powinny być zaprojektowane z myślą o użytkownikach, a nie tylko w celu zapewnienia 100% pokrycia czy debaty o tym, jaki odsetek testów warto napisać.
Skoncentruj się na testach, które pokazują rzeczywiste błędy, na które mogą natrafić użytkownicy, i które nie przeszkadzają w realizacji celów. Testy powinny być zaprojektowane z myślą o użytkownikach, a nie tylko zapewniać 100% pokrycia czy zachęcać do dyskusji na temat tego, jaki procent konkretnego typu testu należy napisać.