Witam,
Zastanawia mnie jak poprawnie wyglada tworzenie testow funkcjonalnych. Otoz czy testujemy body response czy tez zmienne, lub czy to i to. Juz przedstawiam dokladniej o co mi chodzi.
dajmy na to ze mamy controller:
controller:
[code]def index @products = Product.find :all
end
i teraz tescik:
a)
test “test list products” do
get ‘index’
assert @response.body.include?products(:one).name
assert @response.body.include?products(:two).name
assert @response.body.include?products(:three).name
assert @response.body.include?products(:four).name
assert @response.body.include?products(:five).name
end
b)
test “test list products” do
get ‘index’
assert assigns(:products).size == 5
end[/code]
?
a co w przypadku kiedy uzywamy helpera w widoku, ktory nam np. zmieni dajmy na to name na duze litery (ot taki glupi przypadek dla zobrazowania problemu), wtedy musimy jechac tak czy tak z response.body?
test "test list products" do
get 'index'
assert @response.body.include?products(:one).name.uppercase
assert @response.body.include?products(:two).name.uppercase
assert @response.body.include?products(:three).name.uppercase
assert @response.body.include?products(:four).name.uppercase
assert @response.body.include?products(:five).name.uppercase
end
?
Oh, to zależy mocno od Ciebie, nie ma czegoś takiego jak ‘poprawne testowanie kontrolerów’ (controllery to jakas dziwna mieszanka ang i pol? )
Ja ostatnio zakładam tak, że jeśli kontrolery są restowe, bardzo proste i 'cienkie" to nie ma sensu ich testować oddzielnie. Jeśli jednak są jakieś dziwne akcje to powinny być przetestowane – w takim wypadku nie sprawdzam jednak wyjścia HTML. Zazwyczaj jeśli jest coś dziwne w kontrolerze to powinno być przeniesione do modelu i spokój.
Takie podejście ma sens dodatkowy jeśli używasz np. cucumber do testowania aplikacji, to już same testy dla kontrolerów czy widoków moim zdaniem są zbędne.
Zgadzam się z przedmówcą. Jeśli nie piszesz biblioteki, która ma być wykorzystywana w kilku innych aplikacjach (wtedy warto zainwestować w dogłębne testowanie eksponowanego interfejsu), to zdecydowanie lepiej skoncentrować się na testach akceptacyjnych. Zwykle jeśli jest jakiś problem na niższym poziomie (który mógłby zostać wykryty np. przez testy jednostkowe), to i tak zamanifestuje się na wyższym poziomie. W szczególności dotyczy to problemów z typem parametrów, tak często wskazywanych przez zwolenników statycznej typizacji.
Moim zdaniem nalezy testowac caly kontroller, nawet jezeli jest to standardowy kontroller restowy. Napisanie testow do standardowego kontrollera to jakies 10 min a dzieki temu mamy zapewniona spojnosc i wiem ze nic w przyszlosci nam sie nie rozjedzie.
[quote=zantor]jasne, nawet jesli mamy controller zlozony z
def index
end
wg mnie warto napisac nawet test:
get ‘index’
assert_response :success[/quote]
Jasne. Ale ja wolę mieć to jako np.:
Given the user is not logged in
When the user opens the main page
Then the page is displayed
Oczywiście “the main page”, może być np. “the news index page”, etc. etc. Chodzi o to, że wymagania funkcjonalne definiowane z wykorzystaniem historyjek użytkownika mają podwójną wartość:
można uruchamiać je jako testy (z użyciem cucumbera np.)
stanowią bardzo czytelną dokumentację wymagań projektu, która zrozumiała jest dla klienta.
[quote=apohllo]Given the user is not logged in
When the user opens the main page
Then the page is displayed
[/quote]
Cucumber jest bardzo fajny, ale przy czasie wykonania całości 5-10 minut (a to jest niewielki test suite) ja wolę nie dopisywać do cucumbera rzeczy, które nie testują interfejsu użytkownika. Są też czasami przypadki, w których nie wszystko łatwo jest sprawdzić cucumberem, wtedy też wspomagam się spec/controllers.
Ja bym powiedział tak jak:
Jeżeli nie wiesz co masz przetestować to staraj się testować jak najwięcej: modele, helpery, kontrolery, cucumber. Jak już się nauczysz każdej z tych technik, to będziesz mógł ocenić, które testy są Ci potrzebne w danym przypadku.
)