Witam,
Chciałbym dość poważnie zająć się tematyką testowania swoich aplikacji Rails w wersji 3.
Czy ktoś może polecić jakieś artykuły w języku polskim. Własne wskazówki dot. tego tematu będą także mile widziane 
Ucz się angielskiego. Bez angielskiego ten biznes nie ma sensu.
Tak, ucz się angielskiego – po polsku możesz się uczyć z dawno przeterminowanych książek i niekompletnej dokumentacji.
Polskie tłumaczenie przewodników po Rails, o testowaniu aplikacji. Co prawda opisuje wersje 2.3, ale zmiany są praktycznie niewielkie.
http://www.apohllo.pl/guides/testing.html
Teraz jedziemy z reklamą (jawną, nie krypto) i podbijaniem PR.
Wprowadzenie do testowania BDD na przykładzie cucumbera i sinatry.
http://rubysfera.pl/2010/04/sinatra-cucumber-capybara/ - częśc pierwsza
http://rubysfera.pl/2010/05/uwierzytelnianie-w-sinatrze-z-data-mapperem/ - część druga
Tak bardziej ogólnie:
http://rubysfera.pl/2010/03/10-porad-o-rspec/
http://rubysfera.pl/2010/07/10-porad-o-cucumber/
I na po świętach jak już zrozumiesz czym się różni rspec od cucumbera i capybary (na pewno nie wcześniej, bo Ci się pomerda)
http://rubysfera.pl/2010/03/warte-uwagi-pickle/
http://rubysfera.pl/2010/07/testowanie-steak-ruby/
http://www.pragprog.com/titles/achbd/the-rspec-book - kawa na ławę o testowaniu BDD w Rubym, ale po angielsku i w sumie dość długie.
To chyba tyle. Dużo więcej nie znajdziesz w polskim internecie.
Ok, jest jeszcze to:
http://railis.eu/posts/40 - BDD, nowoczesne testowanie i Rspec
http://michalorman.pl/blog/2010/03/behavioral-driven-development-z-rspec/
Aha, i Drogomir pewnie zaraz napisze, żeby olać rspeca i zając się test/unit.
[quote=sajrox]Chciałbym dość poważnie zająć się tematyką testowania swoich aplikacji Rails w wersji 3.
Czy ktoś może polecić jakieś artykuły w języku polskim. Własne wskazówki dot. tego tematu będą także mile widziane :)[/quote]
Osobiste sugestie:
- Olej rspeca pomimo, że jest na topie. Wybierz jakieś prostsze, mniej magiczne narzędzie, jak test-unit, minitest, shoulda.
- Zacznij od porządnego testowania logiki biznesowej, bo to jest najprostsze.
- Pamiętaj, że ten temat ewoluuje, autorytety się ścierają i nie znamy jeszcze odpowiedzi na wiele pytań, a zbiór dobrych praktyk jest niekompletny.
Nie napiszę, bo obecnie nie potrafię powiedzieć, które z tych 2 narzędzi jest miażdżąco lepsze, są po prostu inne. Czasami używam test/unit, czasami rspeca, zależy od sytuacji, od projektu i od teamu.
Lać Drogusa - ja napiszę: olać RSpec i Cucumber, użyć test-unit ;-). To ostatnie z narzędzi jest miażdżąco lepsze i uniwersalne ;-D.
Najważniejsze to pisać testy (z sensem), to czego się używa to tak naprawdę kwestia gustu.
Coby nie było: olać Cucumber 
Zanim zaczniecie flamewary.
Nie ważne czym. Ważne żeby te testy były.
Nie ważne czym. Ważne by olać Cucumber
Wszystkich, którzy kazali olać Cucumber, proszę o wytłumaczenie dlaczego.
Ja się z tą opinią całkowicie zgadzam, ale ciekawią mnie Wasze powody i opinie o tym narzędziu.
Wszystkim chodzi o olanie Cucumbera, jako narzędzia, a nie olaniu testów integracyjnych ogólem.
Używałem cucumbera przez jakiś czas i mi się bardzo podobał, lecz im dłużej pisałem w nim testy bym bardziej męczące to dla mnie było, bo miałem wrażenie że piszę 2x za dużo kodu. Najpierw piszę stepy, dodaję ścieżki i inne rubiowe rzeczy a później jeszcez to opisuję po angielsku. W momencie gdy klient, osoba nie techniczna, tester, czy kto kolwiek inni niż programista piszący aplikację, nie czyta i nie pisze scenariuszy w cucumberze, uznałem że bez sensu jest się męczyć.
Można pisać testy integracyjne w czytym rubim - zobacz steak’a, albo w ogóle nie używać żadnej abstrakcji i użyć “gołej” capybary wraz z test/unit lub rspecem. Tak wygląda jeden z moich testów - https://gist.github.com/593497
Pisz testy. Pisz testy integracyjne. Jeżeli cucumber jest dla Ciebie wygodny, używaj go do tego celu.
Uważam, podobnie, jak Strzałek, iż używanie Cucumbera bez klienta (tj. bez całej otoczki, którą daje BDD i współpracy z klientem w tworzeniu feature’ów i scenariuszy w plain text) nie ma sensu i jest sztuką dla sztuki. Co z tego, że dostajemy pięknie napisane scenariusze i dokumentacje poszczególnych funkcji, skoro nikt poza nami (ewentualnie innymi członkami zespołu programistycznego) nie będzie tego czytał?
Samo testowanie integracyjne uważam za bardzo ważne, w pewnych przypadkach nawet mógłbym zdecydować się na olanie testów jednostkowych na rzecz integracyjnych, ale tak, jak napisałem powyżej, bez klienta dużo łatwiej i z mniejszym narzutem można wykorzystać steaka, który zdejmuje z nas - testerów dodatkową pracę, poświęconą na pisanie 2x prawie tego samego (stepów oraz ich definicji). Dodatkowo myślę, że testy pisane w steaku będą dla testerów/programistów tak samo czytelne, jak scenariusze Cucumbera.
@qoobaa pisał ostatnio na naszym blogu dlaczego preferujemy test/unit od RSpeca oraz dlaczego unikamy shoulda—warto poczytać: http://objectreload.com/articles/2010/09/thoughts-on-testing-part-1.html
Artykuł pokrywa się z moimi doświadczeniami:
- nie używać frameworków ze skomplikowanymi DSL-ami (zwłaszcza tymi, które udają że pisze się po angielsku a nie w ruby…)
- minimalizować zagnieżdżenia kontekstów
- minimalizować setupy - dążyć do samowystarczalnych przypadków testowych (a już na pewno setup, jeśli jest, musi być blisko testu i nie być rozbity na wiele kontekstów)
Drobny niuans: cos.should == cos to chyba nie w Shouldzie. Tam nie ma tego głupiego DSL-a, używa się normalnie asercji test/unita assert_equal.
Świetny artykuł, dzięki za linka:)
Można używać Shouldy również w RSpec’u
Można używać Shouldy również w RSpec’u[/quote]
Tak tak, ale to już nie wina Shouldy, a na nią było psioczenie
W artykule jeśli chodzi o .should to informacja dotyczy RSpeca albo kombinacji shoulda + matchy.