Wskaż rodzaj testów, które przeprowadza się podczas fazy tworzenia kodu źródłowego
A. testy kompatybilności
B. testy wydajnościowe
C. testy wdrożeniowe
D. testy jednostkowe
Testy jednostkowe to, moim zdaniem, absolutny fundament solidnego programowania. Są to niewielkie, automatyczne testy, które programista pisze zwykle równolegle z kodem albo nawet przed nim, jeśli stosuje się TDD (Test-Driven Development). Chodzi o to, żeby każda najmniejsza część programu – funkcja, metoda czy klasa – była dokładnie sprawdzona, czy zachowuje się zgodnie z założeniami już na etapie pisania kodu. W praktyce wygląda to tak: piszesz sobie funkcję, która np. liczy VAT, i od razu piszesz kilka testów, które sprawdzają, czy dla różnych wartości zwraca ona poprawne wyniki. Gdy coś się zmieni w kodzie, testy jednostkowe pozwalają od razu wychwycić, że coś zepsułeś (albo, oby nie, ktoś inny). Standardy branżowe, jak np. ISTQB czy wytyczne IEEE 829, bardzo mocno podkreślają wagę testów jednostkowych – bez nich zarządzanie jakością oprogramowania jest po prostu niemożliwe na dłuższą metę. W praktyce nawet proste projekty szybko bez nich zamieniają się w chaos. Co ciekawe, dobrze napisane testy jednostkowe ułatwiają refaktoryzację, bo masz pewność, że po zmianach wszystko działa jak należy. W mojej opinii, jeśli ktoś naprawdę poważnie myśli o pracy w branży IT, powinien umieć pisać testy jednostkowe z marszu.
Wiele osób zaczyna od myślenia, że testy wydajnościowe lub kompatybilnościowe to coś, co można robić już w trakcie pisania kodu, ale jednak tak nie jest. Testy wydajnościowe polegają na sprawdzaniu, jak szybko działa cały system albo jego większa część pod różnym obciążeniem – robi się to raczej po zintegrowaniu większych fragmentów aplikacji, nie w momencie pisania pojedynczych funkcji czy klas. Podobnie jest z testami kompatybilności – one sprawdzają, czy program działa poprawnie na różnych systemach operacyjnych, przeglądarkach albo w połączeniu z innymi aplikacjami. Tego typu testy są ważne, ale zwykle nie mają sensu, dopóki nie masz gotowej lub prawie gotowej aplikacji. Testy wdrożeniowe z kolei pojawiają się na samym końcu procesu – dotyczą sprawdzania, czy oprogramowanie zostało prawidłowo zainstalowane i czy działa w środowisku produkcyjnym. To już jest zupełnie inny etap, kiedy kod jest gotowy, przetestowany na innych poziomach i deweloperzy mają nadzieję, że wszystko pójdzie gładko. Często spotykam się z podejściem, że testowanie można zostawić na później, a to jest, szczerze mówiąc, bardzo ryzykowne. Największym błędem jest niedocenianie testów jednostkowych i mylenie ich z większymi testami integracyjnymi, wydajnościowymi czy wdrożeniowymi. To właśnie testy jednostkowe są najbliżej kodu źródłowego i to ich się używa podczas jego pisania – pozwalają szybko wychwycić błędy, zanim rozrosną się w poważniejsze problemy. Branża już dawno pogodziła się z tym, że testy jednostkowe to nie jest żadna fanaberia, tylko podstawowe narzędzie każdego programisty dbającego o jakość. Bez nich ryzykujesz, że małe błędy prześlizgną się do dalszych etapów i później naprawa jest dużo trudniejsza oraz bardziej kosztowna.