W poprzednim artykule Testy jednostkowe i TDD – czy to dobry pomysł? pisałem trochę o moich przemyśleniach na temat TDD. Nie wiedziałem jednak, że jest jeszcze sporo osób, które nie rozumieją samej idei testów jednostkowych (czy ogólnie testów automatycznych). W tym artykule postaram się odpowiedzieć na pytanie: po co w ogóle są testy jednostkowe?
Co to są testy jednostkowe?
Zacznijmy od podstaw i tego co to są testy. Testy jednostkowe pomagają nam testować kod, który napiszemy, lub który zmieniamy. Dzieje się to zwykle w sposób automatyczny (zestaw testów jest odpalany przy budowaniu aplikacji). Co ważne testy takie powinny działać w sposób powtarzalny.
Co mi dają takie testy?
Testy jednostkowe to bardzo wiele korzyści. Problem w tym, że aby te korzyści dostrzec, trzeba przez jakiś czas używać testów jednostkowych. Dlatego wielu programistów poddaje się przy pierwszym podejściu do testów. Korzyści nie widać od razu, trzeba poświęcić czas, żeby ich się nauczyć.
Jedną z takich korzyści, która może przekonać do stosowania testów jest redukcja małych i powtarzalnych błędów, których poprawianie jest bardzo żmudne i zarazem frustrujące. Nic nie odbiera chęci do pracy tak skutecznie, jak te same błędy każdego dnia. Kolejnego dnia idziesz do pracy z nadzieją, że może dzisiaj pokodujesz coś nowego, coś fajnego może… I znowu to samo. Jakiś if dodany „na szybko” nie w tym miejscu co trzeba, jakiś NullPointerException. W jednym miejscu poprawione, w innym się popsuło. I tak każdego dnia. Naprawdę to wszystko odbiera chęci! Wiem to, bo też przez to przechodziłem. I byłem jeszcze przy tym tak zarobiony, że nie miałem czasu na dorabianie nowych funkcjonalności, bo stare cały czas się psuły.
I cóż, niektórzy mogą twierdzić, że ich to nie dotyczy, ale prawda jest taka, że wszyscy popełniamy błędy. A jak istnieje gdzieś jakaś aplikacja, w której nie było testów i nie ma w niej błędów, to znaczy, że większość została już poprawiona.
Testy pozwalają także przetestować kod tak, żeby sprawdzić, czy działa on tak jak myślisz, że działa. Bo to, że ty myślisz, że twój kod działa poprawnie nie znaczy, że tak w rzeczywistości jest.
Kolejna rzecz to to, że testy wymuszają na programiście dbanie o kod aplikacji. Przede wszystkim Twój kod musi być testowalny, żeby można było pisać do niego testy. Testy pomagają pisać mniejsze klasy i metody. Bo trudno jest przetestować metodę, która ma kilkaset linii kodu.
I ostatnia z zalet którą wymienię. Testy dają ochronę przed regresją. Za każdym razem, gdy zmieniasz coś w aplikacji, powinieneś odpalić testy by sprawdzić, czy twoje działania nie spowodowały jakiś problemów. Bez testów po prostu nie masz szansy się o tym dowiedzieć w krótkim czasie. Błędy wychodzą dopiero na produkcji.
Jakie powinny być dobre testy?
Nie wystarczy pisać testów. Trzeba to robić dobrze. Przede wszystkim testy muszą mieć odpowiednią nazwę. Każda metoda testowa musi mieć nazwę, która odzwierciedla to, co dany test testuje. Bez dobrej nazwy często trudno określić na pierwszy rzut oka co dany test testuje. Testy powinny być czytelne i przejrzyste tak, żeby każdy programista mógł w kilka sekund zrozumieć, co dany test testuje.
Testy powinny zawierać stosunkowo małą ilość kodu tak, żeby ogarnięcie ich było łatwe. A wszystkie dodatkowe metody można przenieść do klas pomocniczych.
Ale nie wystarczy tylko pisać ładnych testów. Trzeba jeszcze zadbać o to, by wszystkie przypadki brzegowe zostały przetestowane odpowiednio. Czasem trzeba pomyśleć nad tym, co testujemy. Może okazać się, że trzeba przetestować o wiele więcej niż to, co na początku zakładaliśmy. Na to nie ma dobrego przepisu, po prostu trzeba zawsze zastanowić się nad tym co testujemy. I wykazać przy tym odrobinę zaangażowania.
Zaangażowanie to jedna z kluczowych rzeczy w pisaniu dobrych testów. Bardzo łatwo jest odróżnić testy osób, które piszą je bez przekonania bez zaangażowania i „na siłę”. Od tych, które są pisane przez osoby angażujące się odpowiednio w proces pisania testów.
W przypadku tych pierwszych, pojawia się od razu pytanie: „Czy to wystarczy?”. I można to rozpatrywać w wielu aspektach: czy ilość testów jest wystarczająca, czy asercje w poszczególnych testach są odpowiednie itd. Natomiast co do tych drugich, to często pojawia się pytania: „Czy tutaj nie jest czegoś za dużo?”, np. niektóre testy wydają się nadmiarowe, albo testują dodatkowo to co już zostało przetestowane w innych testach.
Wymówki, żeby nie pisać testów
Jedną z najczęściej powtarzanych wymówek jest „Nie mam czasu na pisanie testów”. Jeśli programista organizuje sobie czas tak, że nie starcza go na testy, to nigdy nie będzie miał na nie czasu. Będzie za to siedział nad bugami od świtu do zmierzchu 😉 Oczywiście, że pisanie testów zajmuje czas i wydłuża development nowych funkcji. Ale to tak naprawdę inwestycja w jakość oprogramowanie, które wytwarzasz. Wraz z jakością przychodzi spadek liczby błędów i łatwiejsze utrzymanie aplikacji, co oznacza, że oszczędzasz czas, gdzie indziej.
Kolejna to „Biznes nam nie pozwala, bo nie ma na to czasu” 😉 To ciekawa wymówka, bo biznes woli zwykle wydawać mniej i mieć mniej problemów z oprogramowaniem, więc stosunkowo łatwo ich przekonać, że testy są potrzebne.
„U nas się nie sprawdziły” 😀 albo jeszcze lepiej „U nas się nie sprawdziły, bo nie było nikogo, kto by tego pilnował”. To dobra wymówka, dla programistów, którzy przychodzą do pracy czasem coś porobić. Czasem napiszą kawałek kodu, czasem poprawią jakiś błąd. I tak czas mija od wypłaty do wypłaty.
KURS TESTY JEDNOSTKOWE
Kompleksowy kurs o testach jednostkowych
Podsumowanie
Testy to jeden z ważniejszych elementów tworzenia oprogramowania. Ciągle niestety wielu programistów nie stosuje ich, a nawet kwestionuje ich zasadność nie znając w ogóle zalet płynących z ich stosowania. Dla tych, którzy chcieli by dowiedzieć się więcej na temat testów, przygotowałem specjalnego ebooka z najważniejszymi informacjami o testach jednostkowych. Po co mi testy jednostkowe?