Wyzwania związane z testowaniem
W projektach oprogramowania testowanie może być skomplikowane i wydawać się przytłaczające. Jeśli istniejące projekty nie są kompilowane przy użyciu wielu testów, kod jest zwykle złożony i mniej niezawodny. Zrozumienie problemów i potencjalnych pułapek testowania ma kluczowe znaczenie dla udanego projektu oprogramowania.
Brak testowania
Gdy projekty oprogramowania są kompilowane bez testów (lub niewystarczająca liczba testów), kod może się pogorszyć, stać się kruchy i trudniej zrozumieć. Testy sprawiają, że kod jest odpowiedzialny za jego zachowanie, a po wprowadzeniu testów wymusza na inżynierze ułatwienie testowania kodu.
Istnieje kilka pozytywnych skutków ubocznych testowania, które można rozpoznać w kodzie. Funkcje i metody napisane z myślą o testowaniu mają tendencję do następujących:
- Nie dłużej niż około tuzina linii długości.
- Zamiast robić wiele różnych rzeczy, musisz mieć jedną odpowiedzialność.
- Mają pojedynczą lub minimalną ilość danych wejściowych zamiast wielu argumentów i wartości.
Krótkie, pojedyncze i minimalne dane wejściowe ułatwiają zrozumienie, konserwację i testowanie kodu. Gdy testowanie nie jest zaangażowane, często widać, że mniejsze funkcje rosną w kilkaset wierszy, robiąc wiele rzeczy. Kod ewoluuje w ten sposób, ponieważ nie ma odpowiedzialności uniemożliwiającej niepotrzebne złożoność.
Starszy kod
Jednym ze sposobów myślenia o nietestowanym kodzie jest oznaczenie go jako starszego kodu. Często można znaleźć nietestowany kod w projektach oprogramowania. Kod może nie być testowany z kilku powodów, w tym brak doświadczenia z testowaniem lub praktykami programistycznymi, które nie pozwalają wystarczająco dużo czasu na rozważenie testowania w ramach tworzenia oprogramowania.
Jak już wspomniano, jedną z cech nietestowanego kodu jest to, że trudno go zrozumieć i często może stać się złożony z tego samego powodu. Skutkiem ubocznym wszystkich tych problemów jest to, że kod jest jeszcze trudniejszy do rozwiązania, powodując, że funkcje (lub metody) ciągle rosną z większą częścią logiki i bardziej powiązanymi ścieżkami kodu.
Mniejsza funkcja, tym łatwiej będzie testować.
Powolne i zawodne testy
Mimo że istniejący zestaw testów jest świetny na początek, może to być problematyczne, gdy zawiera powolne lub zawodne testy. Deweloper będzie bardziej skłonny do uruchamiania testów często, jeśli udostępniają szybką opinię. Jeśli zestaw testów trwa kilka godzin zamiast minut (lub sekund), deweloper nie może sobie pozwolić na jego uruchomienie tak często. Gdy pętla opinii działa wolno, proces programowania zostaje naruszony.
Podobnie można znaleźć sytuacje, w których test może zakończyć się niepowodzeniem bez wyraźnego powodu. Zawodne testy są czasami nazywane łysymi. Główną obowiązkiem zestawu testów jest wykazanie, że testowany kod spełnia oczekiwania określone przez same testy. Jeśli testy są zawodne, nie można powiedzieć, czy kod musi zostać zmieniony lub czy poprawka wprowadziła regresję.
Zawodne (lub niestabilne) testy powinny zostać naprawione lub w inny sposób usunięte z pakietu. Nie każdy test może być szybki, a niektóre typy testów, takich jak testy integracji, mogą być powolne. Ale posiadanie solidnego zestawu testów, który zapewnia szybką opinię, jest niezbędne.
Brak automatyzacji
Gdy testowanie nie jest wykonywane w zautomatyzowany sposób, łatwo zapomnieć, co należy przetestować i przetestować, może stać się podatne na błędy. Nawet w przypadku małych projektów oprogramowania łatwo zapomnieć, czy zmiana warunku w funkcji może mieć (negatywny) efekt uboczny gdzieś indziej w bazie kodu. Gdy deweloper oprogramowania nie ma zadania zapamiętania, co i kiedy należy przetestować, ponieważ wszystko się dzieje automatycznie, to zaufanie do oprogramowania, testów i ogólnego systemu wzrasta.
Automatyzacja polega na usuwaniu powtarzających się zadań i zmniejszaniu kroków niezbędnych do wykonania akcji. Testowanie automatyczne może wystąpić, gdy kod jest wypychany do repozytorium zdalnego, a nawet przed scaleniem. Zapobieganie nieprawidłowemu kodowi przechodzenia do kodu produkcyjnego bez ręcznego sprawdzania ma kluczowe znaczenie dla niezawodnej aplikacji.
Narzędzia do testowania
Niektóre wyzwania wynikają z braku testowania, podczas gdy inne są związane z słabymi środowiskami testowymi i nie wiedzą, jakie techniki należy zastosować. Wspomnieliśmy już o starszym kodzie w tym module i o tym, jak nietestowany kod może stale rosnąć i zwiększać złożoność. Narzędzia pokrycia testów mogą dokładnie poinformować, które ścieżki kodu są testowane i które nie są objęte istniejącymi testami.
Poleganie na bibliotekach narzędzi i testowaniu to doskonały sposób na zmniejszenie nakładu pracy, jaki trzeba wykonać w celu utworzenia dobrych testów. W zależności od testowanego języka i aplikacji należy znaleźć rozwiązania, które mogą ułatwić testowanie i zwiększyć niezawodność.
Oto kilka przykładów tych narzędzi:
- Narzędzie pokrycia testów do raportowania przetestowanych i nietestowanych ścieżek kodu.
- Moduł uruchamiający testy, który może zbierać, wykonywać i ponownie uruchamiać określone testy.
- Środowisko ciągłej integracji/ciągłego wdrażania, które może automatycznie uruchamiać testy i zapobiegać scalaniu lub wdrażaniu wadliwego kodu.