Jednym z ostatnich rodzajów długów jakie chcę poruszyć to testy. Testy we wszelakiej postaci, od jednostkowych, przez integracyjne, specyfikacji, smoke, white i black box do obrzydliwych ręcznych. Brak testów to najgorsza rzecz jaką możemy zrobić.
W każdej normalnej branży (a nie takiej, gdzie większość to pryszczaci kolesie z problemami interpersonalnymi 
) czyli takiej o solidnych podstawach ukształtowanych przez lata praktyki, normą są testy.
Budowlańcy robią testy wytrzymałości betonu, mieszanek, nawet próbki z każdej partii wylewanego betonu. Testują rozciągliwość stali. Testują przenikalności cieplne i milion innych rzeczy.
Przemysł motoryzacyjny jest pełen testów od – znowu – wytrzymałości poszczególnych elementów, stopów i kompozytów. Przez jazdy testowe trwające długie miesiące zanim pojazd trafi do salonów aż na testach zderzeniowych kończąc.
Lekarze i ich wynalazki są tak dokładnie testowane, że wprowadzenie nowego leku trwa latami zanim zacznie się testy na ludziach, a to dopiero początek drogi do wprowadzenia na specyfików na rynek. Zresztą sami lekarze po odebraniu dyplomu nie idą od razu do pracy aby np. operować – swoją drogą to by były jaja, “może mi ktoś zszyć pacjenta bo na zajęciach ze zszywania mnie nie było”.
Dziwnym trafem jeśli chodzi o programowanie, to często okazuje się, że testy są albo niepotrzebne albo sprowadzają się do “przeklikania” aplikacji przez 5 minut po skompilowaniu ostatnie najświeższej najlepszej wersji – czasem nawet te 5 minut to za dużo. Czy jesteśmy tacy genialni? Obawiam się, że nie. Większość z nas to po prostu ignoranci. Brak testów to nic innego jak brak pewności czy system robi to co powinien. Prosty program to setki a czasem nawet tysiące małych założeń. Każde takie założenie ma wpływ na końcowy produkt więc wypadało by każde założenie zweryfikować czy jest poprawne. Bez automatycznych testów zdajemy się na los. Praktyka wykazuje, że w większości przypadków to się sprawdza. Jednak użytkowników oprogramowania najbardziej denerwuje tych kilka przypadków gdzie są błędy. Nikt nie doceni genialności Twojego programu, jeśli mały błąd będzie powodował, że aplikacja będzie się sypać co 5 minut.
Jakoś wszystkie branże potrafią zgodzić się, że testy są kluczowe a pryszczaci kolesie z problemami interpersonalnymi programiści ciągle mają z tym problem.
Żeby odciążyć siebie z pamiętania wszystkich założeń i odciążyć się z ręcznego klikania po aplikacji należy stosować testy automatyczne. Testy automatyczne mogą się wykonywać cały czas, w kółko. Nie kosztują nas więcej niż prąd do komputera. Nie masz komputera do testów? Użyj komputera na którym programujesz. Postaw maszynę wirtualną i niech przez całą noc kiedy nie używasz komputera (albo dzień w zależności od preferencji) niech on pracuje dla Ciebie. Niech testuje.
Testy automatyczne powinny trwać możliwie krótko aby szybko dawać informację czy wszystko jest okej oraz powinny być łatwe i tanie w utrzymaniu bo przecież nikt nie będzie tygodniami pisał/poprawiał/zmieniał testów. Należy też pamiętać, że testy to narzędzie a nie cel sam dla siebie – aha…. “przeklikanie” aplikacji to nie są testy aplikacji.
“Ale my nie mamy czasu na testowanie”
Czy aby na pewno? Ile czasu tracicie na poprawianie błędów? Ile czasu tracicie na poprawianie powracających błędów? Gdyby zainwestować kilka dni pracy na przygotowanie sensownego, automatycznego zestawu testów okaże się, że zyski będą większe niż początkowa inwestycja a z czasem ten zysk będzie rósł. Dobry zestaw testów pozwoli szybko wyłapać błąd a im szybciej wyłapiemy błąd tym taniej go poprawimy. Dla przykładu: jeśli po zrobieniu błędu 5 minut później otrzymamy o tym informację to poprawiamy to momentalnie. Jeśli błąd pojawi się tydzień później to trzeba odszukać źródło błędu (debug i krok po kroku, krok po kroku) a potem poprawić. Zazwyczaj to trwa dużo dłużej niż w sytuacji początkowej (5 minut po napisaniu błedu). Najgorsza sytuacja to taka, gdzie klient nam zgłasza błąd. Oprócz procedury odszukiwania źródła błędu dochodzi jeszcze czas klienta, który musi to zgłosić i wytłumaczyć co się dzieje, czas supportu, który musi klienta wysłuchać a potem bład zarejestrować i pewnie jeszcze czas kogoś kto musi błąd potwierdzić a po poprawieniu sprawdzić czy na pewno został on naprawiony. Całkiem spora rozrzutność. Brak jakichkolwiek testów powoduje, że najczęściej mamy sytuację jak w ostatnim przykładzie. I jak teraz wygląda wymówka “my nie mamy czasu na testowanie”? Nie macie czasu na testowanie bo robicie błędy i nic innego nie robicie tylko w kółko poprawiacie błędy – które mogły by być wychwycone przez dobry zestaw testów.
