Kwalifikacja: INF.04 - Projektowanie, programowanie i testowanie aplikacji

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.