Rails 3 + RSpec 2, problem z testami funkcjonalnymi

Zielona szkoła
1

W kontrolerze utworzyłem testową akcję GET :index2, w aplikacji używam authologic i declarative_authorization.

[code=ruby]require ‘spec_helper’

describe MainsController do
render_views

describe “#index2” do
it “index2, HTTP 200” do
response.should be_success
end

it "index2, render" do
  response.should render_template("index2")
end

end
end[/code]
Po wywołaniu tych testów otrzymuje taki komunikat błędu

[code]Failures:

  1. MainsController#index2 index2, render
    Failure/Error: response.should render_template(“index2”)
    expecting <“index2”> but rendering with <"">.
    Expected block to return true value.

    (eval):2:in `assert_block’

    ./spec/controllers/mains_controller_spec.rb:12:in `block (3 levels) in <top (required)>’[/code]

Jestem kompletnie zielony w pisaniu testów a sposób ich pisania jest dużo gorzej opisany niż pisanie aplikacji w Railsach.

2

Musisz najpierw wywolac request np.

get :index2

Sam RSpec jest dobrze zdokumentowany cucumberami :wink: -> http://relishapp.com/rspec/rspec-rails/v/2-6/dir/controller-specs

3

A czytaleś?
http://guides.rubyonrails.org/testing.html#functional-tests-for-your-controllers

4

to są testy za pomocą mechanizmu Railsów, a ja pisałem o RSpec

5

Dlatego lepiej zacząć od TestUnit-a, który jest dobrze udokumentowany i dopiero później używać RSpec-a. Inna sprawa, że RSpec daje tylko ładniejszą? składnie, a zasada działania obu bibliotek jest identyczna.

6

TestUnit i RSpec opisany jest w ten sam beznadziejny sposób, więc jeśli RSpec ma lepszą składnię to zostanę przy RSpec

7

To kwestia gustu bardziej, bo niektórzy nie trawią składni Rspeca. Dlatego ciężko powiedzieć, że składnia jest lepsza czy gorsza. Jest inna. I ja bym raczej powiedział, że w przypadku railsów test unit jest opisany dużo lepiej (guides!), o ile nie masz książki o rspecu, w której jest wszystko fajnie zebrane.

Co do gustów, to tutaj masz stanowisko naszego forumowego konserwatysty jeżeli chodzi o zewnętrzne biblioteki: http://objectreload.com/articles/2010/09/thoughts-on-testing-part-1.html :wink:

Swoją drogą, fajnie jest znać obie biblioteki, obie mają swoje wady i zalety. Zgadzam się z argumentamiy Kuby z artykułu powyżej i lubię test unit z tych powodów, ale z kolei konteksty i custom matchers z rspeca też się czasami przydają (chociaż część osób powie, że nie powinno się kontekstów używać).

Przy okazji, spróbuj na przykład w rspecu napisać łatwo wyspecjalizowane klasy takie jak w railsach do testowania różnych elementów (np. ActionView::TestCase albo klasy do testowania generatorów czy coś w tym stylu) - w rspecu to jest jakoś magicznie pospinane, w test unit masz po prostu klasę z odpowiednimi metodami, po której możesz dziedziczyć i zrobić sobie prosto swoją wersję. Tak samo jak shared_examples_for. Używałem tego kilka razy, ale nigdy jeszcze nie użyłem bez zaglądania w dokumentację. W test unit tworzysz po prostu moduł z metodami testowymi i go includujesz w test case’ach.

8

To jak już odgrzewamy starego flejma, to odgrzejmy też stare kontrargumenty:

9

Nie rozumiem w jaki sposób wiąże się to z dyskusją o składni. Rozmowa dotyczy API, a nie tego w jakim runnerze to odpalisz. Widziałem tego gista i jak ktoś potrzebuje funkcji dostępnych w runnerze rspeca, to na pewno mu się przyda, ale tak czy siak kod będzie musiał pisać używając TestCase’ów albo describe’ów i contextów. Chyba, że ktoś chce to połączyć, ale wtedy współczuję :wink:

Zresztą jak to jest flejm, to znaczy, że flejmuję sam ze sobą, bo tak jak napisałem, uważam, że obie biblioteki są fajne i obie mają swoje wady i zalety.

EDIT:

I takie jeszcze kontrolne pytanie. Jak masz kod z użyciem swojego własnego TestCase’a, ale odpalasz go używając polecenia rspec, to piszesz w rspecu czy w test/unit? :wink: