Jesteś tutaj
Główna > Kreatywne IT > Testy dla zielonych, czyli dlaczego nie warto zaczynać aplikacji bez testów

Testy dla zielonych, czyli dlaczego nie warto zaczynać aplikacji bez testów

Testy jednostkowe – bezsensowne wymaganie wydłużające pisanie aplikacji. Czy na pewno? Z pewnością taki obraz możemy bardzo często wynieść z uczelni. Czy to jednak absolutna prawda? Temu zagadnieniu poświęciłem prezentację na Łódź User Ruby Group – czyli comiesięcznym spotkaniu Railsowców organizowanym w 6 dzielnicy w Łodzi. Sama prezentacja dostępna jest w formie PDF w zakładce „Materiały”. Zapraszam na krótką powtórkę w formie artykułu – jeśli zaczynasz dopiero przygodę z Ruby On Rails/programowaniem/testami to ten tekst napisany jest specjalnie dla Ciebie. Dowiesz się przede wszystkim „Po co, do cholery pisać testy?!”, jak wygląda napisanie prostego testu w RoR, oraz oczywiście jak przygotować sobie do tego środowisko. No to ruszamy!

LRUG 23 06 2016

Po co, do cholery, pisać testy?

To zdecydowanie najważniejszy punkt mojego dzisiejszego artykułu oraz środowego LRUGa. Żebyś dobrze to zrozumiał posłużę się aplikacją którą rozwijam po godzinach. Warthog Timer ma pomóc w zmobilizowaniu się przy okazji realizowania różnych umiejętności. Sama główna funkcjonalność jest banalnie prosta. Gdy zaczynasz coś robić (na przykład pracę inżynierską, aplikację internetową czy malowanie obrazu) klikasz „START” na timerze. Gdy kończysz klikasz „STOP” – i w tym momencie tworzy się log_time – jeden obiekt w bazie. Następnie idziesz do statystyk i sprawdzasz ile udało ci się spędzić czasu nad różnymi fajnymi rzeczami. Statystyką która nas dzisiaj zajmie będzie „Najlepszy cel”. Na rysunku poniżej przedstawiam łańcuch metod jaki musi się odbyć od pozyskania danych (calculate_time_from_log_times) do obliczenia ostatecznego celu (best_target).

warthog ciąg

To co warto zauważyć to fakt, że ta metoda na samym dole obliczająca czas jest użyta aż… 8 razy. I to za każdym razem jest  podobny łańcuch. Zastanówmy się więc co będzie, jeśli będziemy chcieli ją nieco zmienić, ale zamiast poprawić – zepsujemy? Oczywiście zarówno ten, jak i każdy inny łańcuch staje się kompletnie do niczego. W tym przypadku więc Warthog byłby kompletnie sparaliżowaną aplikacją. „Ok, co z tego, przecież mogę się przeklikać” ktoś powie. Pewnie – ale ile razy? I za każdym razem gdy coś zmienisz masz zamiar się przeklikiwać we wszystkich możliwych wariantach? Już to widzę…

Tutaj z pomocą przychodzą nam testy jednostkowe. Są to takie małe fragmenciki kodu, drobne instrukcje które mają sprawdzać czy przy odpowiednich parametrach wywołanie danej metody daje pożądany wynik. To rozwiązanie o wiele lepsze, niż popularne „przeklikam się”, gdyż myślimy tylko raz (przy pisaniu), a potem po prostu odpalamy testy zawsze gdy dokonamy jakiś zmian i.. już.

Jak to wygląda w praktyce? Instalujemy potrzebne biblioteki

Ponieważ na co dzień piszę w Ruby on Rails a i prezentacja była oparta na tej technologii, to tutaj dokładnie pokażę jak od 0 zbudować sobie wygodne środowisko do pierwszych, najbardziej podstawowych testów. Potrzebne będzie nam kilka gemów. Wchodzimy w Gemfile (w głównym katalogu aplikacji) i wpisujemy kolejno:

Gdy już to wpiszemy idziemy do terminala i wprowadzamy „bundle install”, co zainstaluje nam wszystkie wyżej wprowadzone gemy. Krótkie wytłumaczenie – Rspec to gem odpowiedzialny za obsługę testów, jest można powiedzieć „głównym filarem” który wszystko spaja. Ponieważ jednak jest to środowisko testowe a nie development, musimy stworzyć tam nasze obiekty. Do tego posłuży nam Factory Girl (Nie pytaj, nazwy tutaj naprawdę bywają dziwne…). Na koniec bardzo przydatna sprawa – Database Cleaner pomoże nam czyścić bazę przed każdym testem. Dzięki temu na każdy test popatrzymy jako osobną część i zachowamy nad nim pełną kontrolę. Skoro już zainstalowałeś gemy, wejdź ponownie w terminal i wprowadź komendę rails generate rspec:install. Po tym zabiegu powinieneś w głównym katalogu aplikacji mieć folder „spec”. Na ten moment wpisz w terminal „rspec” i… zobacz jak świetnie wykonały Ci się twoje wszystkie (0) testy. Gratuluje! Wejdź w folder spec, a następnie spec_helper.rb. tutaj wklej następujący kod który obsłuży czyszczenie bazy danych w odpowiednich momentach.



Piszemy test!

Zabierzmy się za napisanie testu. Tutaj mogę niestety jedynie pokazać Ci jak wygląda to u mnie, w Warthog’u. Testujemy omawianą wyżej metodę calculate_time_from_log_times. Wygląda ona następująco:

Ponieważ znajduje się ona w serwisie (taka klasa w której umieszczamy logikę – na przykład różne algorytmy), stworzyłem w folderze „spec” nowy katalog – „services”, zaś w nim „targets_stats_service_spec.rb” – czyli nazwę mojego serwisu z dodanym na końcu „_spec” (To kwestia konwencji, która w Ruby on Rails jest święta! Dlatego też się do niej stosuj).  Wewnątrz napisałem 3 testy – widoczne pod spodem. Zwróćmy uwagę na kilka elementów:

  • Context – opisuje pewien kontekst naszych prac. Ja napisałem jaką metodę w nim będę testował.
  • It – ten blok to właśnie test jednostkowy. Tutaj opisujemy już konkretniejsze działanie – np. jaką liczbę powinna zwrócić metoda.
  • Expect(cośtam).to eq(cośtam) – oczekiwany wynik testu.

Warto zwrócić uwagę na to FactoryGirl.create(). To właśnie stworzenie obiektu w bazie. Żeby stworzyć „matrycę” takiego obiektu najpierw utworzyłem folder „factories” wewnątrz „spec”, a następnie stworzyłem odpowiedniki modeli – np. log_time.rb, target.rb czy user.rb. Pokazuję przykładowy kod – user.rb żebyś wiedział jak tworzyć proste Factory Girl.

Gdy już napisałeś testy, jedyne co musisz zrobić aby je odpalić to wejść do terminala i wpisać… rspec. Klikasz enter i już! Testy samoczynnie idą, zaś na koniec „wypluwają” raport. Jeśli któryś się nie powiódł to prawdopodobnie masz coś nie tak z metodą (lub z samym testem). Gdy uda Ci się doprowadzić wszystko do pozytywnego stanu możesz poklepać się po pleckach – wykonałeś(/łaś!) kawał dobrej roboty!

Co dalej?

Na koniec chciałbym bardzo mocno zaznaczyć, że testy to gigantyczny temat który zaledwie tutaj musnęliśmy. Zachęcam Cię do eksplorowania Internetu w celu dalszego szlifowania umiejętności związanych testowaniem. Pamiętaj, że od tego zależy jakość twojej aplikacji, a przecież nie chcemy robić niczego byle jak prawda? Testy oszczędzają mnóstwo czasu i nerwów oraz dają Ci większą kontrolę nad tym co dzieje się z twoją aplikacją. Oczywiście jeśli będziesz chciał poznawać te tematy, służę pomocą – możesz napisać do mnie maila lub złapać mnie na którymś z LRUG’ów;-)

P.S.

Warthog jest w wersji pre-alfa, ale jeśli chcesz spróbować przejąć kontrolę nad czasem który poświęcasz na rzeczy które Cię budują, to zachęcam do korzystania na stronie warthogtimer.com. Przed rejestracją po prawej stronie zajrzyj w znak zapytania który podpowie Ci, jak korzystać z serwisu. A jeśli będziesz miał uwagi, pytania lub sugestie również odnośnie rozwoju aplikacji – zamieniam się w słuch : – )

 

Ja nazywam się Marek Czuma,  a to jest IT-Blog Wolnego Człowieka

piszę do Ciebie prosto z Łodzi

Marek Czuma
Autor Bloga Republikańskiego. Chrześcijanin, Polak, Łodzianin. Wierzy w ludzi i ich możliwości, kocha pomagać innym. Uważa, że człowiek wolny kształtuje siebie poprzez własne wybory oraz pracę. Poza tym fan Wiedźmina i CD Projektu - zarówno na giełdzie, jak i w działaniu.

Dodaj komentarz

Top