Kod cucumber + rspec-rails requests & controller

Zakład patologii kodu
1

Witajcie :slight_smile:

Pisząc testy dla swojej strony domowej, mam pewien problem. Znaczy wszystko działa, ale nie wiem czy dobrze poukładałem to wszystko :

Cucumber:

Feature: Manage homepages
In order to see homepage
As a guest
wants going to homepage

Scenario: Going to homepage
Given I am guest
When I go to the homepage
Then I should see “xxx”
And I should see “Personal Site & Blog”
And I should see “Home”
And I should see “About”
And I should see “Portfolio”
And I should see “Blog”

Czyli opis strony po wejściu (2 pierwsze będą do zmiany, 4 kolejne to linki do podstron).

Dalej zgodnie z zasadą testy w rspec :

najpierw mam plik opisujący layout jako test integracyjny (fragment):
describe “GET ‘/’” do # Home Page, HomeController
before(:each) do
get ‘/’
end

it "should be sucessfull" do
  response.should be_success
end

it "should have a Home page at '/'" do
  response.should have_selector("title", :content => "xxx Personal Site")
end

it "should render 'home/index' template" do
  response.should render_template('home/index')
end

it "should render 'about/index' template" do
  response.should render_template('about/index')
end

end

oraz test dla kontrolera, na razie pusty. I teraz zastanawiam się, czy zostawić requests tak jak jest, czy coś usunąć i co ewentualnie ważnego dodać ? Jako title dałem sposób identyfikacji strony, ale title jest ustawiane w kontrolerze, więc czy jest to poprawny sposób, oraz czy nie powinienem tego przenieść do kontrolera ?
W kontrolerze oczywiście będą opisane działania typowe dla kontrolera, ale tutaj nie wiem czy dobrze kombinuję.

Dzięki za uwagę
Pozdrawiam ! :slight_smile:

btw. możecie polecić jakieś dobre pozycje (książki, artykuły, itp) związane z dobrymi nawykami budowania testów (głównie BDD) ?

2

może lepiej:

[code] In order to read recent content and navigate to other sections
As a guest
I want to

Scenario: see navigation on the homepage
…
Scenario: see recent posts on the homepage
…
Scenario: see contact form on the homepage (co tam potrzebujesz)[/code]
Testowanie to temat rzeka. Postaram się naskrobać artykuł o tym jak ja to robię i co propaguję w firmie i podrzucę linka.

3

Ale kilka takich przemyśleń z głowy:

  • używaj test::unit, na początku aby poznać czym tak na prawdę RSpec różni się od Test::Unit. Wcale nie jest powiedziane że RSpec będzie Ci bardziej pasował.
  • traktuj testy integracyjne jako testy czarnej skrzynki, gdzie testerem jest reprezentant użytkownika końcowego, używającego przeglądarki. Cucumber sprawdzi się dobrze, podobnie jak Capybara
  • jeśli olejesz sobie scenariusze Cucumbera, równie czytelne testy można napisać zarówno w RSpec jak i Test::Unit z wykorzystaniem Capybary http://jeffkreeftmeijer.com/2011/acceptance-testing-using-capybaras-new-rspec-dsl/
  • jeśli masz dobrze napisane testy integracyjne, to zastanów się 2 razy czy testy kontrolera są do czegoś potrzebne. Jeśli masz zamiar testować to samo w 2 miejscach, na 2 sposoby, to będziesz musiał utrzymywać 2x większy kod testów.
  • Cykl (T/B)DD powinien wyglądać w ten sposób:
    1. Piszesz test integracyjny
    2. Uruchamiasz test integracyjny
      • jeśli wynikiem jest niespodziewnay błąd, poprawiasz test integracyjny
      • jeśli wynikiem jest spodziewane niepowodzenie wynikające z braku bądź błędnej implementacji kodu w systemie, idziesz dalej
      • jeśli wynikiem jest sukces, bierzesz kolejne zadanie i wracasz do punktu 1.
    3. Piszesz test jednostkowy (najczęściej do modelu) opisujący fragment kodu potrzebnego do implementacji funkcjonalności opisywanej przez Twój test integracyjny
    4. Uruchamiasz test jednostkowy
      • jeśli wynikiem jest niespodziewnay błąd, poprawiasz test jednostkowy
      • jeśli wynikiem jest spodziewane niepowodzenie wynikające z braku bądź błędnej implementacji kodu w systemie, idziesz dalej
      • jeśli wynikiem jest sukces to zastanawiasz się czy wymagane jest więcej kodu modułów aplikacji aby zaspokoić wymagania opisywane testem integracyjnym. Jeśli tak, wracasz do punktu 3. Jeśli nie, idziesz do punktu 6
    5. Piszesz tylko tyle kodu aby zaspokoić wymagania testu jednostkowego, wracasz do punktu 4.
    6. Piszesz dodatkowy kod (kontrolera, javascript) który korzysta z funkcjonalności kodu opisanego testami jednostkowymi i wracasz do punktu 2.
4

mam powiązane pytanie, w pliku features/web_steps.rb generowanym przez cucumber-rails jest info żeby skasować tenże plik i pisać własne testy wyższego poziomu. Czy ten plik to rzeczywiście duże zło :slight_smile: skoro ma pare przydatnych kroków, które często będą się powielać.
hubert:chętnie przeczytam taki artykuł, bo o ile tutoriali do poszczególnych narzędzi jest pełno to mało tekstów o bardziej ogólnym spojrzeniu