Proszę poradźcie.
Mam aplikacje. Modele pokryte testami (Test::Unit)
I co dalej?
Czy testy funkcjonalny sa konieczne?
Capyabara, Cucumber, Steak, Selenium, Culurity Webraty, Shoulda … itp itd.
Dużo tych komponentów.
Testy są dla mnie więc nie ma znaczenia ich czytelność dla nie-programisty. Jest trochę javascriptu i fajnie jakby się dało przejść przez zewnętrzny serwis (np. dotpay)
Jaki zestaw sobie złożyć?
Pozdr.
[quote=pski]Proszę poradźcie.
Mam aplikacje. Modele pokryte testami (Test::Unit)
I co dalej?
Czy testy funkcjonalny sa konieczne?
Capyabara, Cucumber, Steak, Selenium, Culurity Webraty, Shoulda … itp itd.
Dużo tych komponentów.
Testy są dla mnie więc nie ma znaczenia ich czytelność dla nie-programisty. Jest trochę javascriptu i fajnie jakby się dało przejść przez zewnętrzny serwis (np. dotpay)
Jaki zestaw sobie złożyć?
Pozdr.[/quote]
Na początek warto podzielić te narzędzia na 2 grupy, żeby nie mieszać jabłek z gruszkami:
Zacznijmy od pierwszej grupy. Jeżeli testy są dla Ciebie, to odrzuciłbym od razu cucumbera. Steak jest nakładką na rpeca, więc żeby niepotrzebnie nie mieszać też bym go wyrzucił. Po co dorzucać jakieś zależności. Z powodzeniem możesz testować w test unit.
Jeżeli chodzi o narzędzia z drugiej grupy, to odradzam używanie bezpośrednio API do przeglądarek lub pseudo przeglądarek typu selenium, celerity itp. Dlaczego? Capybara i webrat zapewniają API, które pozwala bez zmian w testach korzystać z więcej niż jednego narzędzia. A z kolei z tych 2 capybara ma zdecydowanie lepsze podejście, przy czym obsługuje selenium, celerity/culerity i rack/test, więc możesz bez żadnych zmian w testach używać dowolnego z tych narzędzi.
Dlatego w tym wypadku najlepsze będzie combo test/unit + capybara. Żeby móc łatwo testować z test unit i capybarą, wystarczy wrzucić config do test helpera:
require "capybara/rails"
Capybara.default_driver = :rack_test
Capybara.default_selector = :css
i stworzyć klasę, która będzie udostępniała API dla testów integracyjnych:
class ActiveSupport::IntegrationCase < ActiveSupport::TestCase
include Capybara
include Rails.application.routes.url_helpers
end
Użycie jest banalnie proste:
[code]require ‘test_helper’
class PostsIntegrationTest < ActiveSupport::IntegrationCase
visit new_post_path
fill_in “Title”, :with => “Yupi!”
fill_in “Body”, :with => “Something”
click “Save”
assert page.has_content?(“Post has been successfully created”)
within “#posts” do
assert page.has_content?(“Yupi!”)
assert page.has_content?(“Something”)
end
end[/code]
Testy funkcjonalne przydają się, jeśli aplikacja posiada jakieś mechanizmy uwierzytelniające lub autoryzację. Jeśli kontroler nie odbiega od “scaffoldowego” (respond_with) to pisanie testów mija się z celem. W testach funkcjonalnych wygodnie testuje się też przypadki fałszowania formularzy (można łatwo dodać parametry, do których nie istnieją odpowiednie pola na formularzach). Do testów integracyjnych polecam Capybarę - dzięki niej mamy jedno API do testowania bez przeglądarki (rack-test) i w przeglądarce (webdriver). Zanim ulegniesz obecnej modzie i zaczniesz pisać “ogórkowe historyjki”, polecam spróbować napisać kilka najzwyklejszych testów integracyjnych (capybara + test-unit). Pisanie historyjek to duży przerost formy nad treścią - szczególnie w przypadku gdy jedyną osobą, która będzie je czytać, będziesz Ty. Zwykłe testy integracyjne są łatwiejsze w utrzymaniu (test znajduje się w jednym miejscu, nie jest porozbijany na kilka plików jak w przypadku Cucumber).
edit: Dobrze jest też zastanowić się co chcemy testować. Aby uniezależnić testy kontrolerów od modeli (skupić się wyłącznie na samym kontrolerze) przydają się jakieś narzędzia do stubowania/mockowania (mocha, rr, itp.). Pamiętaj, że elementy takie jak: walidacje, mass assignment, wysyłanie maili, itp. są już testowane w modelach.
Dzięki bardzo. O to mnie chodziło, wiem już co, jak, gdzie i z czym 
Dołączać nic, wystarczy zmienić driver. Możesz ustawić, żeby selenium było domyślnym wyborem:
Capybara.default_driver = :seleniummożna też w czasie testów ustawić current_driver:
Capybara.current_driver = :culerityPrzejrzyj sobie README capybary najlepiej: http://github.com/jnicklas/capybara
A czy moglibyście rozwinąć jeszcze temat frameworków rSpec, Shoulda, Cucumber, Steak? Co z czym i dlaczego? Mówimy oczywiście o BDD. Będę wdzięczny za opis najlepszych praktyk.
shoulda - po to byś pisał testy tak, że po roku będziesz wiedział co testujesz(wymusza sposób pisania testów i i ich nazywania, jest ładniej). Głównie testy jednostkowe.
cucumber - po to byś mógł napisać specyfikacje wymagań (po angielsku) i na podstawie tylko tego tekstu uruchamiał testy. Specyfikacje możesz uzgadniać i ustalać z klientem. Głównie testy funkcjonalne, integracyjne
A co byście powiedzieli na temat: co zamiast Cucumbera? Pisanie historyjek może i jest fajne, ale jak wspomniał qoobaa pisanie w pure ruby jest łatwiejsze w utrzymaniu. Poza tym piszę sam - a czym jest pisanie historyjek dla samego siebie? Zastanawiam się nad steak’iem. Używa ktoś tego ? A może jakieś inne gemy do testowania integracyjnego/funkcjonalnego bez użycia cucumbera.
Steak.
Tak naprawdę jest to biblioteka podpinająca Ci do RSpeca Capybarę (bądź Webrata) i dorzucająca kilka helperów. Sprawuje się wyśmienicie
Jak używasz rspeca, to może być steak, jeżeli nie, to lepiej zostać przy test/unit (przykład powyżej).
Pytanie tylko czy na pewno jest potrzebna kolejna nakładka? Steak dodaje głównie tyle, że można dopisać opis historyjki i zmienia “it” na “scenario”. W jednym ze swoich projektów wolałem zostać przy rspecu bez żadnych rozszerzeń, dorzucenie obsługi czegoś takiego jest banalnie proste:
[code]require ‘spec_helper’
require ‘capybara/rails’
require ‘capybara/dsl’
Rspec.configure do |config|
config.include(Capybara)
Capybara.default_driver = :selenium
Capybara.default_selector = :css
end[/code]
Teraz w pliku, który ma być testem integracyjnym wystarczy zrobić:
[code]require ‘integration_helper’
describe “Managing posts” do
example “Creating new post” do
# …
end
end[/code]
Pisząc te słowa nie chcę oczywiście nikomu wmawiać, że steak jest beznadziejny, w innym projekcie mam zainstalowanego właśnie steaka i działa ok. Chciałem tylko pokazać, że do testów integracyjnych wcale nie potrzeba instalować żadnych dodatkowych gemów. Wybór pozostaje w tym wypadku bardziej kwestią gustu, bo feature’y są bardzo podobne.
Ja mam lekką aplikację, której testy integracyjne piszę w czystym rspecu + capybara i jest bardzo wygodnie i przejrzyście.
Capybara właśnie pożarła Steaka: http://jeffkreeftmeijer.com/2011/acceptance-testing-using-capybaras-new-rspec-dsl/ … choć ostatnio coraz bardziej podoba mi się podejście Capybara + Test::Unit.
Cała wiedza w tym wątku jest nadal aktualna czy się coś pozmieniało?
Prawie cała, na pierwszy rzut oka wydaje mi się że zamiast “include Capybara” robisz teraz “include Capybara::DSL”, ale to szczegół.
Można się też zainteresować bbq od wrocławskiego druga: https://github.com/drugpl/bbq , które pozwala wygodnie operować na kilku użytkownikach, którzy coś klikają po apce. (Tak, jestem jednym z mainteinerów).
@paneq
No dzięki za wkład, ale jako mało ogarnięta osoba w testach skorzystam z stabilnych rozwiązań.
No to będzie kombo
Test::Unit + Capybara.
Mam jeszcze pytanie odnośnie testów obciążeniowych.
Z tego tutoriala wynika że dość dobra opcja to Test::Unit
http://guides.rubyonrails.org/performance_testing.html
Dobrze rozumuje?
Bbq jest stabilne. Po prostu nie próbujemy się z nikim ścigać na numerki.