ostatnio załapałem bakcyla testowania (chyba zmądrzałem ;)) i naszła mnie jedna myśl. Mam funkcjonalność i mam do niej napisane testy rspec, myślę, że dosyć solidnie i pokrywają one wszystkie funkcjonalności (stosunek kodu do testów to 1:15). Czy jest sens teraz dopisywania jeszcze kodu testów Cucumbera? Czy istnieje jakaś granica po przekroczeniu której testów jest zbyt dużo? I nie chodzi mi o takie testy co się dublują tylko o takie dobre i spełniające swoje zadania, to czy testów nigdy za wiele?
Wdzięczy też bym był za rady odnośnie używania narzędzi, które uzupełniają się z RSpecem, i które mogę używać z rozsądkiem jeżeli używam już wspomnianego RSpeca.
W rspecu można pisać zarówno testy jednostkowe jak i integracyjne, możesz pisać testy requestów itd. Jako, że piszesz o cucumberze, zakładam, że Twoje testy są jednostkowe i pytasz, czy pisać akceptacyjne. Odpowiedź na to pytanie jest ciężka, bo nie wiem co tworzysz. Ogólnie rzecz biorąc jak najbardziej, testy akceptacyjne są dobrym uzupełnienim jednostkowych.
Bez testów akceptacyjnych, jeśli Twoja aplikacja używa np. javascriptu, możesz nie zauważyć, że jakaś funkcjonalność przestała działać z powodu tak głupiej zmiany jak nazwa klasy w kodzie html. Możesz nie zauważyć, że jakiś kontroler się wykrzacza przy zapisywaniu obiektu, mimo, że w testach jednostkowych będzie wszystko jak należy.
Druga sprawa, dobrze kombinujesz pytając o przeginanie, bo dużo testów oznacza dużo więcej pracy przy zmianach - lepiej mieć trochę mniej, ale bardziej przemyślanych niż testować wszystko. Na przykład jestem przeciwny testom, które sprawdzają, czy dany model ma daną asocjację itp., to pisanie linijki kodu, która sprawdza, czy w modelu jest inna linijka kodu - jeśli ta asocjacja nie zostanie nigdy użyta, to po co to testować? Jeśli zostanie użyta, to lepiej przetestować przypadek jej uzycia.
I nie używaj cucumbera, jeśli nie pracujesz z klientem. To się moim zdaniem kompletnie mija z celem. Musisz się napracować, żeby zdefiniować w angielskim przeróżne kroki, które pod spodem i tak mają kod ruby. Polecam rspec + capybara.
zakładam, że wcięło Ci „.”, i powinno być 1:1.5 – w przeciwnym wypadku, zakładając, że nie piszesz oprogramowania do obsługi reaktora jądrowego, robisz to źle.
Odnośnie testowania, polecam jeden z najnowszych ruby drama.
a ja bym powiedział, że nie używaj nigdy cucumbera. Jeden z większych bullshitów jaki znam, to taki, że „dzięki cucumberowi, klient będzie mógł sam pisać testy”. Jest tylko jeden problem – taki klient wygląda tak.
Bez przesady, takich bajek, to chyba nikt rozsądny Ci tu nie powie ;).
Nie lubię cucumbera, ale wiem, że są ludzie, którzy siadają z klientem i tak tworzą najważniejsze user stories. I podobno to się udaje. Nie wiem, nie zamierzam próbować. Nie chodziło mi o to, żeby kozystać z cucumbera zawsze gdy się pracuje z klientem. Patrzę na to z drugiej strony - jeśli nie ma klienta, to na pewno nie warto.
Generalnie testy powinny być dokumentacją wiedzy programisty o tym, jak działa aplikacja. Włączając w to (zwłaszcza!) znalezione bugi i to, jak zostały naprawione.
Pamiętaj że testy służą, przede wszystkim, zapobiegnięciu regresjom. Czyli przed napisaniem testu zadaj sobie pytanie “czy istnieje możliwość pojawienia się babola, który wyłoży ten i tylko ten test”. Jeśli nie, to nie warto go pisać.
Co do cucumbera, to jeżeli się go dobrze używa, to nie jest imho taki bezużyteczny. Kłopot w tym, że większość osób (w tym ja kiedyś, bo teraz go nie używam), nie używa go tak jak się powinno (tzn. do testów akceptacyjnych).
Jasne, ze jak masz:
Given I am on the homepage
When I click "foo"
Then the page should contain ".some-css"
To dużo łatwiej można napisać:
visit root_url
click_link "foo"
page.should have_css(".some-css")
Kwestia jest taka, że to co napisałem powyżej w cucumberze nie powinno tak wyglądać, dlatego między innymi Aslok usunął web_steps (tzn. wszystkie “click link”, “then I should see” itp). Do tego dochodzą jeszcze różne przegięcia typu testowanie wszystkich przypadków wystąpienia błędów na formie czy praw dostępu z każdą kombinacją.
Czemu mam zmarnować kilka kwadransów swojego życia na oglądanie czegoś, co dałoby się zawrzeć na stronie-dwóch maszynopisu?
Oraz: oto dlaczego nie lubię TED talków.
[quote=Tomash]Czemu mam zmarnować kilka kwadransów swojego życia na oglądanie czegoś, co dałoby się zawrzeć na stronie-dwóch maszynopisu?
Oraz: oto dlaczego nie lubię TED talków.[/quote]
Też tak podszedłem do tej prezentacji, obejrzałem i wnioski mam takie:
jeżeli chodzi o unit testy, które nie dotykają zewnętrznych rzeczy, to całkiem nieźle mu wychodzi wytłumaczenie dlaczego to warto robić
cały talk można by zrobić ze 2 razy szybciej, ale prelegent ma tendencję do “bajdurzenia”
Ja jestem w trakcie czytania i potwierdzam, genialna książka, najdroższa jaką w życiu kupiłem ale jest tego warta. Dałem w grudniu 116zł z przesyłką z brytyjskiego Amazona. Przyszła w 3 dni.
Ktoś robił nawet takie gemy, które pozwalały na testowanie, czy w modelu jest dana asocjacja, co sprowadzało się do tego, że trzeba było napisać linijkę, która sprawdza, czy w kodzie jest inna linijka.
