Testowanie aplikacji
Dlaczego testować kod?
Parzę kawę z pustym wzrokiem. Jestem ciągle przy tym bugu. Skąd się wczoraj wziął? Dodano tylko nowe dane na serwerze i apka padła. Dobrze że nie było jeszcze wydania na produkcję. Błąd pojawia się tylko w czasie działania i przez chwilę widać ekran, gdzie nic się nie zepsuło i następuje crash.
Kod wygląda naprawdę dobrze. Dodane są jakieś testy i nie zwracam na nie uwagi. Co może iść nie tak. Sprawdzam błąd. Coś z svg. Hmm… Ale wyświetla się wszystko i apka wybucha.
Mijają godziny a ja sprawdzam kolejne linie. Parzę kolejną kawę i przychodzi olśnienie. Znacie ten moment gdzie nagle jesteście pewni rozwiązania? To jest właśnie to. W svg mam kółko z postępem. Dane do niego są brane z serwera. Z serwera przychodzi 0/0 bo dane są puste. A co się robi żeby policzyć procent?
Dokładnie. Dzielenie. Dzielę przez zero. Biegnę do laptopa. To naprawdę to. Stracone godziny przez jedno 0. Coś czego nie przewidziałem, że może wystąpić.
Strasznie głupi błąd. Najgorzej że debugger pokazuje błąd w bibliotece a nie w moim kodzie. Co dodatkowo utrudnia pracę. Typowe życie programisty.
Ale czy tak musi być? Wróćmy do tytułu. Wiele osób powie, że to głupie pytanie. Stwierdzą "szkoda czasu" albo "to obowiązek, jak możesz nie testować?". Często nie rozumieją po co to robić.
Poprawne przetestowanie zaoszczędziłoby mnóstwo czasu. Mogłem od razu dopisać testy do różnych przypadków.
Zastanówmy się nad korzyściami płynącymi z testowania. Oprę się tylko na moich doświadczeniach.
Najpierw testuj, potem pisz kod.
To najcięższa zasada. Byłem przyzwyczajony pisać kod od razu i potem dopisywać testy. Kiedy zmieniłem podejście i na samym poczatku robię test, widzę że:
- nie testuję tylko "happy path" lub specyficznych przypadków, które czasami były zbędne bo nie testowały, tylko przechodziły
- mogę o wiele szybciej zapytać klienta o jego zdanie i wartość biznesową, bo mam szansę z góry pomyśleć o możliwych ścieżkach i co się wydarzy
- nie ufam własnemu kodu (bo go jeszcze nie napisałem) i dzięki temu nie pomijam ważnych testów, pozwala mi to nie uznać, że: "ten kod raczej się nie wywali"
- widzę problemy, które będzie trzeba rozwiązać i mogę szybciej dopytać innych, dostać jakiś feedback
- jak dotykam czyjegoś kodu nie boję się, że go zepsuję, najpierw pokrywam testami swój kod i dodaję żeby reagował na zmiany w czyimś kodzie, więc nawet jak ktoś zmieni coś co wpłynie na mój kod, ta osoba zobaczy co nie przeszło
Staram się postępować zgodnie ze ścieżką: red-green-refactor. Czyli piszemy test, który nie zadziała, bo nie ma jeszcze nawet kodu do niego. Robię najprostszy test. Piszę kod. Przechodzi. Poprawiam co mi się nie podoba i sprawdzam. Potem dodaję bardziej skomplikowany test i tak w kółko.
Najlepiej o tym opowiada książka: TDD. Techniki programowania sterowanego testami.
Zalety testowania.
- łatwość dokonywania zmian, mogę coś zmienić i jak jest jakaś zależność w innym miejscu to dostaję informację o tym bo test nie przejdzie. Wtedy usuwam zależność albo poprawiam kod
- szybciej znajduję błędy, bo jestem w stanie je wykryć w czasie pisania kodu bo ciągle uruchamiam testy, w przypadku javascript jest to o tyle lepsze, że nie muszę ciągle sprawdzać w runtime jak to działa
- pisząc z kimś innym ciężej o błędy, bo nasze testy pilnują aby nie zepsuć kodu
Wady testowania.
- dłużej wszystko zajmuje, poświęcasz więcej na pisanie testów, (chociaż pozwala Ci zredukować czas potrzebny na szukanie błędu, często zmniejsza też szansę na wystąpienie błędu)
- musisz napisać masę testów, to wychodzi bardzo dużo kodu
Moja opinia.
Obecnie pisanie testów to dla mnie podstawa. Nie jako obowiązek, tylko jako fajne narzędzie do rozwijania umiejętności. Uczy pisać poprawnie kod. Trzymać się dobrych zasad. Na przykład: KISS (keep it simple stupid), czyli kod ma robić jak najmniej rzeczy. Testy wykluczają Ci często pisanie gigantycznych, generycznych funkcji czy klas. Przy flow agile jest to bardzo ważne, bo kilka razy przemyślisz czy warto robić coś generycznego jak użyjesz to tylko raz. A najczęściej programiści mają ochotę na siłę trzymać się reużywalności.
Testowanie React Native.
To jest obecnie technologia, w której pracuję. Utworzyłem ostatnio zbiór snippetów, które pomogą testować aplikacje napisane w react native.
https://github.com/Patys/testing-react-native
Ciągle rozszerzam o kolejne pomysły i możliwości te repozytorium. Każdy przypadek testów jest inny, ale czasami warto mieć jakiś boilerplate, z którego utworzysz swoje testy. Miło jak zostawisz gwiazdkę albo pomożesz to rozwijać o kolejne przypadki.
Co zrobiłem z tym błędem?
Dodałem testy, które sprawdzają czy nie ma tam zera. Potem dodałem warunek żeby nie dzielić przez zero. Sprawdziłem testy. Działa. Napisałem artykuł na bloga i dodałem do testing-react-native na github ten przypadek.