Moim celem jest odpalenia testów aplikacji testowej gema w folderze głównym tegoż gema. I tu jest taki problem, w jaki sposób wskazać cucumberowi katalog, w którym znajdzie sobie featuresy? Myślałem że wystarczy odpowiednie ustawienie RAILS_ROOT, ale on to robi jakoś inaczej. W helpie nie zauważyłem, aby była opcja podania tego katalogu w linii poleceń.
Jakieś sugestie?
$ cucumber --help
Usage: cucumber [options] [ [FILE|DIR|URL][:LINE[:LINE]*] ]+
Jestem mistrzem spotrzegawczości. Wielkie dzięki
Nie chcę zakładać nowego wątku więc się podłączę tutaj 
Mam pytanie dotyczące Cucumbera. W jednym ze screencast’ów Ryan’a Bates’a (episode: http://railscasts.com/episodes/155-beginning-with-cucumber) jest pokazany przykład jak używać cucumber.
Jest tam test dodający do bazy danych dwa artykuły, i sprawdzający, czy poprawnie się one wyświetliły.
Fragment testu:
Given I have articles titled Pizza, Breadsticks
...
...
Then I should see "Pizza"
And I should see "Breadsticks"
A co, jeżli w widoku index.html.erb będziemy mieli taki kod:
"Pizza"
"Breadsticks"
<%=# i tutaj jakiś kod erb o który myślimy, że działa dobrze, chociaż wcale tak nie jest %>
Sprawdziłem, i cucumber taki test przepuszcza (co jest logiczne z punktu widzenia implementacji webrata), co z tym zrobić? Przecierz nie będziemy zmieniać znaczenia kroków w pliku webrat_steps.rb …
Oczywiście przykład jest dość prosty i tak banalnego błędu raczej nie popełnimy, ale chodziło mi tutaj o pokazanie przykładowego błędu, który przejdzie testy. Co z tym zrobić?
[quote=krzyczak]"Pizza"
"Breadsticks"
<%=# i tutaj jakiś kod erb o który myślimy, że działa dobrze, chociaż wcale tak nie jest %>
Sprawdziłem, i cucumber taki test przepuszcza (co jest logiczne z punktu widzenia implementacji webrata), co z tym zrobić? Przecierz nie będziemy zmieniać znaczenia kroków w pliku webrat_steps.rb …
Oczywiście przykład jest dość prosty i tak banalnego błędu raczej nie popełnimy, ale chodziło mi tutaj o pokazanie przykładowego błędu, który przejdzie testy. Co z tym zrobić?[/quote]
No, chyba o to chodzi żeby zweryfikować czy to się wyświetla. A na pozostały kod erb trzeba napisać kolejne testy … Chyba że nie o to chodzi …
Przede wszystkim myśleć podczas robienia testu. Po drugie, tak jak w owym railscaście, najpierw pisać test potem kod, bo wtedy na bieżąco widzisz testowany kod i zobaczysz tego typu sprawy.
Po za tym narzędzie jest narzędziem, niczym więcej, więc nie powinno się mieć oporów przed dostosowywaniem go do własnych potrzeb, np. edycji webratowych kroków. btw tam już jest np. krok do znajdywanie elementów w odpowiednim miejscu, np.
Then /^(?:|I )should not see \/([^\/]*)\/ within "([^\"]*)"$/ do |regexp, selector|
within(selector) do |content|
regexp = Regexp.new(regexp)
content.should_not contain(regexp)
end
end
[quote=gRuby][quote=krzyczak]"Pizza"
"Breadsticks"
<%=# i tutaj jakiś kod erb o który myślimy, że działa dobrze, chociaż wcale tak nie jest %>
Sprawdziłem, i cucumber taki test przepuszcza (co jest logiczne z punktu widzenia implementacji webrata), co z tym zrobić? Przecierz nie będziemy zmieniać znaczenia kroków w pliku webrat_steps.rb …
Oczywiście przykład jest dość prosty i tak banalnego błędu raczej nie popełnimy, ale chodziło mi tutaj o pokazanie przykładowego błędu, który przejdzie testy. Co z tym zrobić?[/quote]
No, chyba o to chodzi żeby zweryfikować czy to się wyświetla. A na pozostały kod erb trzeba napisać kolejne testy … Chyba że nie o to chodzi …[/quote]
Nie nie nie
Chodzi mi o to, że w szablonie erb zamiast poprawnego
<% for article in @articles do %>
<%= article.title %>
<% end %>
będziemy mieli na sztywno wpisane stringi “Pizza” i “Breadsticks” (nie ważne z jakiego powdu), oraz kod na przykład taki:
<% for article in @articles %>
<%= 1+1 %>
<% end %>
Wtedy test jaki napisałem wyżej przejdzie, a nie powinien…
[quote=Piotr Misiurek]Przede wszystkim myśleć podczas robienia testu. Po drugie, tak jak w owym railscaście, najpierw pisać test potem kod, bo wtedy na bieżąco widzisz testowany kod i zobaczysz tego typu sprawy.
Po za tym narzędzie jest narzędziem, niczym więcej, więc nie powinno się mieć oporów przed dostosowywaniem go do własnych potrzeb, np. edycji webratowych kroków. btw tam już jest np. krok do znajdywanie elementów w odpowiednim miejscu, np.
Then /^(?:|I )should not see \/([^\/]*)\/ within "([^\"]*)"$/ do |regexp, selector|
within(selector) do |content|
regexp = Regexp.new(regexp)
content.should_not contain(regexp)
end
end
[/quote]
A czyli jednak jest coś co rozwiewa moje wątpliwości. Dzięki !!
Widać muszę się bardziej webratowi przyjrzeć…
Zobacz sobie jeszcze ten wątek: http://rubyonrails.pl/forum/t2305-Refaktoryzacja-‘I-should-see-"...."’-w-cucumberze
Właśnie takiego wątku szukałem !! Jeszcze raz wielkie dzięki!!
To i ja podbije temat schodząc zasadniczo z tematu, ale zostając przy cucumberze. Pisze test aplikacji, który opiera się w z zasadzie na JS/CSS. Ogólnie testy to zabawa w I should see / I should not see, problem jest tylko takie, że w czystym HTMLu to wszystko jest cały czas na stronie, a to czy coś widać czy nie decyduje JS mieszając w CSS. Jak to przetestować w cucumberze? Na WRUGu Drogus mówił o Screw.Unit i tam uderzyłem w pierwsze kroki, ale z tego co widać w dokumentacji, to służy to do testowania funkcji w JS, a nie tego jak to wygląda i działa na stronie.
EDIT: wystarczyło się cofnąć o jeden wrug wstecz. Odpowiedzią jest culerity