Jakiego frameworka do testowania używacie

Dyskusje
1

Przy okazji tego posta: http://blog.caboo.se/articles/2008/11/4/we-ve-stopped-using-rspec wytworzyła się dość długa dyskusja w komentarzach i na liście dyskusyjnej rspeca - http://rubyforge.org/pipermail/rspec-users/2008-November/009873.html

Tak się zastanawiam czego używa się w polszy :wink:

Jeżeli chodzi o mnie, to (wstyd się przyznać) nie napisałem się w życiu dużo testów, ale jeżeli już coś pisałem, to raczej RSpec.

Fajnie by było jakby ludzie bardziej doświadczeni w testowaniu napisali czego używają, dlaczego, i jakie są według nich plusy i minusy danego frameworka.

2

Ja używam rspec-a tak od niecałego roku i generalnie jestem zadowolony. Nie jestem jakoś bardzo doświadczony w testowaniu, ciągle eksperymentuje z tym co testować a czego nie i jak.

Jest tu dużo wątpliwości:

  • czy robić jedno sprawdzenie w teście czy wiele, pierwsze jest niby zgodne z filozofia BDD, ale znowu trzeba napisać masę kodu
  • czy dublować testy, czy robić refactoring jak są podobne, zaoszczędzamy miejsca, ale znowu jest nieczytelne
  • czy testować banalne operacje CRUD w każdym kontrolerze

Te problemy zdaje się najlepiej są rozwiązane w shoulda, gdzie są te makra, które załatwiają większość prostych testów, które w rspecu trzeba pisać ręcznie.

Wielki problem jest z tym czy robić mocki czy nie. Do tej pory zawsze mockowałem modele, bo wszędzie pisali, że musi być izolacja. Ale mockowanie w nawet prostych projektach jest już mocno skomplikowane i uciążliwe, zwłaszcza przy mockowaniu powiązanych obiektów. Jak się doda jakąś nową metodę to zaraz trzeba wszedzie pododać mocki itp. Dlatego powoli od tego odchodzę, chociaż czasami mocki się przydają.

Polecam prezentację na temat testowania Merba http://merbcamp.com/video/katz1.mp4, ale odnosi się też ogólnie do testowania.

Od dwóch dni bawię się cucumberem (następca story runnera), przeportowałem na niego kilka projektów i uważam, że jest świetny :), zwłaszcza ten patent z tablicami FIT, który znacznie upraszcza tworzenie obiektów w scenariuszach i ogólnie powtarzanie kroków a także całych scenariuszy.

Warto się temu przyjrzeć http://github.com/aslakhellesoy/cucumber/wikis/using-fit-tables-in-a-feature

Cucumber ma wbudowaną integrację z webratem, który nieźle się rozwija, dodali opcję do dołączania plików w formularzach, więc można teraz już testować np. wgrywanie zdjęć.

Generalnie teraz mam zamiar w testach stosować tylko scenariusze użycia (ew. jakieś niskopoziomowe rzeczy testować w tym podstawowym rspecu). Ważne przy ich pisaniu jest to, żeby testować tylko publiczne interfejsy, jeśli jest scenariusz dodawania np. produktu to nie sprawdzamy czy produkt jest w bazie, tylko czy się wyświetla na stronie.

Uważam, że scenariusze nadają się do tego najlepiej. Dodatkowo nie trzeba programistów do ich pisania. Plusem cucumbera jest obsługa języka polskiego (chociaż troche lipnie to wygląda, ale chyba lepiej się nie da zrobić).

3

Do niedawna test/unit, od pół roku wyłącznie rspec. Podoba mi się z kilku powodów: hierarchia w testach, osobne testowanie helperów i widoków. Cały czas jednak używam tylko zwykłych testów. Próbowałem używać story runnera ale okazał się zbyt skomplikowany w konfiguracji a testy pisane z jego wykorzystaniem wymagały zbyt dużego nakładu pracy przy zmianach.

Może Cucumber to ułatwi, czas się nim zainteresować

4

Shoulda

5

A co powiecie o tym komentarzu? http://blog.caboo.se/articles/2008/11/4/we-ve-stopped-using-rspec#comment-15483

Jak zaczynałem z RSpecem i wszędzie czytałem “mock mock mock” i zatrzymałem się na tym właśnie, że czułem, że zbyt dużo czasu spędzam na pisaniu i modyfikowaniu mocków. Wiem, że z drugiej strony często utrzymanie dużej ilości fixtures może być problemem (+ czas wczytywania z bazy danych)…

6

Odnośnie tego komentarza, że testowanie zabiera dużo czasu to napiszę tylko tyle, że to czy testować i jak testować zależy od projektu. Jeśli projekt ma porządnych sponsorów, którzy oczekują b. dobrej jakości to oczywiście warto poświęcić czas i wysiłek na testowanie, jeśli natomiast piszemy x-tego cms’a na i sponsor projektu oczekuje od nas 5 site’ów w 5 godzin to nie potestujemy raczej :slight_smile: Railsy pomimo wszystko znajdują raczej zastosowanie w tym drugim scenariuszu więc nie oczekuję z reguły, że zobacze testy w mniejszym lub średnim komercyjnym projekcie (co innego projekty OS).

Osobiście używam RSpec’a chociaż mam zamiar przyjrzeć się “Szudzie”. Mocki też zabierały mi sporo czasu dlatego używam fixtur w testach modeli i kontrolerow, utrzymywanie ich zabiera mniej czasu, zresztą teraz nie trzeba ręcznie aktualizować id kluczy pomiędzy modelami co jest bardzo wygodne. Mocków używam w specjalnych przypadkach, np. testowanie komunikacji z zewn. API. A w ogóle to testuję wg. kolejności:

  1. trudniejsze przypadki których nie mogę od razu “ogarnąć” w głowie ew. kluczową funkcjonalność
  2. bugi które odkrywam w miarę jak projekt się rozwija
  3. całą resztę tylko jeśli mogę sobie na to pozwolić, staram sie znaleźć na to czas
  4. w ogóle nie testuję widoków, przy ilości zmian jakie z reguły wprowadza się do templejtów testowanie widoków w przeciętnym projekcie to super pochłaniacz czasu :slight_smile:

BTW. Śmiać mi się chciało jak przeczytałem jak “caboosers” zrobili upgrade gem’ów i wysiadły im site’y i kilku ludzi musiało to poprawiać co kosztowało kilkanaście tysięcy $, czyja to wina ? No oczywiście Rspec’a a nie tych co dokonywali aktualizacji. Teraz tylko szybki blog post, blame. What a bunch of loosers (caboosers :wink: )

“A poor craftsman blames his tools” :slight_smile:

7

To akurat też mnie zdziwiło w tym poście… Chociaż zawsze plus jest taki, że ciekawa dyskusja się wytworzyła.

Przy okazji wychodzi temat config.gem, który na początku wydaje się genialny, ale przy dłuższym używaniu człowiek zauważa trochę błędów (na przykład po rozpakowaniu niektórych gemów do vendor miałem kłopoty z “native extenstions” pomimo rake gems:build, albo to że przed sprawdzeniem gemów ładuje się całe środowisko railsowe, co skutecznie przeszkadza w insalacji gemów, jeżeli gdzieś w kodzie jest na przykład include Costam - jeżeli Costam jest z gema, to rake się wysypuje, więc i tak trzeba gem zainstalować ręcznie).

Jeżeli chodzi o mocki jeszcze to podobno factory_girl rozwiązuje sporo problemów, będę musiał się tym pobawić.

8

Shoulda podoba mi się coraz bardziej