Co testować, w odróżnieniu od tego, czym jest, to ważne pytanie dla wszystkich zespołów. Testowanie jest sposobem na osiągnięcie celu, a wybór priorytetu testowania różnych części bazy kodu może być trudny.
Najlepszym sposobem na określenie priorytetów jest baza kodu i cele zespołu. Pamiętaj jednak, że chociaż napisanie wielu drobnych testów (na dole piramidy testowania, takich jak testy jednostkowe) o dużej ilości kodu, o dużym zasięgu kodu, niekoniecznie zmniejszają ogólne ryzyko dla Twojego projektu, chociaż nie wymaga to dużo czasu i przepustowości.
Możesz wybrać, co chcesz przetestować w pierwszej kolejności, biorąc pod uwagę główne przypadki użycia aplikacji, witryny lub biblioteki. Możesz na przykład przygotować testy komponentów obejmujące kluczowe części witryny, czyli kluczowe komponenty zwiększające wygodę użytkowników. Na przykład programiści witryny, która umożliwia przesyłanie danych ciągu czasowego i zarządzanie nimi, powinni wyobrazić sobie i przetestować różne sposoby wykonywania tych zadań przez użytkownika.
Inna metoda określania priorytetów polega na zdobywaniu jak największej ilości informacji. Jeśli masz „niebezpieczną”, starszą lub niewłaściwie napisaną część bazy kodu przenoszącą obciążenie, nad którą nikt z Twojego zespołu nie lubi pracować, warto przeprowadzić testy na jej podstawie, aby zachować spójność, zanim ją zignorujesz, albo refaktoryzować ją w celu jej naprawienia. Można to porównać do rusztowania dla budynku, który już został skazany, ale wciąż mieści Twoje centrum danych.
Wymiar
Wprowadzenie koncepcji piramidy testowej, czyli innego kształtu testowania, obejmuje zwykle tylko jeden wymiar testowania: od małego zakresu przez proste testy jednostkowe do złożonych, złożonych, o szerokim zakresie testów – testów jednostkowych lub integracyjnych a testy kompleksowe.
Jednak niektóre z długich list możliwych typów testów nie odzwierciedlają poziomu złożoności, ale stanowią cele lub techniki testowania. Na przykład testy dymne należą do innej kategorii testów, którymi mogą być testy jednostkowe, kompleksowe lub inne. Ich zadaniem jest dać testerom ogólną pewność, że testowany projekt jest w prawidłowym stanie. Testy wizualne mogą być przydatne również w przypadku niewielkiego komponentu lub całej witryny.
Twoja baza kodu będzie miała unikalne wymagania. O wiele ważniejsze może być na przykład dopasowanie do 1 funkcji w bazie kodu poprzez pisanie różnych rodzajów testów w celu sprawdzenia, czy wszystko działa prawidłowo. Nową funkcję, która wymaga przetestowania, rzadko dotyczy pojedynczego komponentu, funkcji lub metody, a jej wpływ na projekt może być szeroko rozłożony i na różne skale.
Priorytety testowania mogą też zależeć od Twoich potrzeb biznesowych. Bardzo techniczne systemy mogą wymagać złożonych testów jednostkowych w celu potwierdzenia, że unikalny algorytm działa prawidłowo. Z kolei wysoce interaktywne narzędzia skupiają się na testach wizualnych lub kompleksowych testach, aby potwierdzić, że złożone dane dotykowe zapewniają prawidłową odpowiedź.
Twoje podejście do testowania
Skup się na testowaniu przypadków użycia swojej bazy kodu niezależnie od jej skali. Wyobraź sobie, jak użytkownik mógłby wykorzystać dowolną część Twojego projektu – może to być pojedynczy komponent, funkcja niższego poziomu lub kompleksowy przypadek użycia. (Może to też ujawnić niedokładności w abstrakcjach na dowolną skalę, jeśli okaże się, że test nie może płynnie współdziałać z kodem testowanym).
Ważne jest, aby każdy przypadek testowy miał jasno określony cel. Duże testy typu catch-all mogą być trudne, tak jak w przypadku innego kodu.
Poza tym programowanie w oparciu o testy
Programowanie oparte na testach to wyjątkowe podejście do testowania – ortogonalne na skalę lub typy – w tym pisaniu testów, które powinny zakończyć się niepowodzeniem, przynajmniej na początku. Stosuje się to zarówno w testach ręcznych, jak i automatycznych: opisujesz cele, które chcesz osiągnąć, ustalasz, czego brakuje w obecnym rozwiązaniu lub kodzie, i wykorzystujesz nieudany test jako wskazówkę, aby znaleźć rozwiązanie.
Oczywiście nie musisz testować wszystkich możliwych scenariuszy w hipotetycznej aplikacji lub komponencie, jeszcze zanim ją utworzysz. TDD ma swoje miejsce i może być pomocny, gdy baza kodu staje się bardziej złożona.
TDD jest też dobrą praktyką przy naprawianiu błędów. Jeśli uda Ci się skodować przypadek odtworzenia błędu, możesz go poddać automatycznemu testowi, który początkowo się nie powiedzie. Gdy naprawisz błąd, testy zostaną pomyślne, co pozwoli Ci określić, czy zmiana przebiegła pomyślnie, bez ręcznego potwierdzenia.
Nieprzezroczyste lub przezroczyste pole
Dotyczy to sposobu testowania dowolnej części systemu. Jeśli jest on nieprzezroczysty, nie będzie można zobaczyć jego wnętrza, np. podczas korzystania z publicznego interfejsu klasy, zamiast sprawdzać jej wnętrze.
Jeśli nie masz konkretnego powodu, aby tego nie robić, lepiej zacząć od nieprzezroczystych pól testów, aby projektować testy na podstawie sposobu użytkowania komponentów i nie rozpraszać uwagi przez działanie ich wewnętrznych funkcji. Jeśli polegasz tylko na „publicznym” interfejsie ścieżki kodu (niekoniecznie publicznym dla użytkowników, ale być może w przypadku innych części kodu), możesz swobodnie refaktoryzować i ulepszać kod, mając pewność, że test wykryje zmiany.
Jednym ze sposobów na zwiększenie przejrzystości kodu „czystej skrzynki” jest wprowadzenie konfigurowalnych elementów, takich jak abstrakcje zależności kodu lub wywołania zwrotne do obserwacji stanu, zamiast być ściśle sprzężone z innymi systemami. Dzięki temu kod jest bardziej odseparowany i możesz udostępniać wersje „testowe”. Możesz też naśladować, gdzie Twój kod wchodzi w interakcje z innymi systemami.