Jako początkujący w Ruby on Rails mam dwa pytania:
- Kiedy wykorzystywać testy integracji, a kiedy kontroleru?
- Czy powinienem testować daną metodę w teście i kontroleru i integracji?
Moglibyście mi na nie odpowiedzieć?
Nie ma jednoznacznej odpowiedzi na te pytania, kwestia jest dyskusyjna i szeroko dyskutowana w środowisku.
Dyskusję na serio rozpętali ludzie z Thoughtbota (rewelacyjna ekipa, jeden z najlepszych zespołów rubiowych na świecie) pisząc tę notkę:
W odpowiedzi Piotrek Solnica (też człowiek którego opinię lepiej poznać i rozważyć) napisał:
Niezależnie od tej dyskusji mogę ci dać dwie bezpieczne odpowiedzi “na pewno”:
- Testy kontrolera na pewno pisz do wystawianego API (lub inny fragment aplikacji którego pojedyncza akcja jest odizolowana od pozostałych, wolna od kontekstu)
- Testy integracyjne na pewno pisz do wielokrokowych (wielostanowych) procesów jakie przechodzi użytkownik w twojej aplikacji. Jeśli jest to sklep, to np. cały flow od trafienia na stronę produktu i dodania do koszyka przez proces podawania danych (i przejścia do płatności) aż do otrzymania komunikatu “twoje zamówienie zostało złożone, czekaj na paczkę”
2 Likes
Ja też w toku nauki często zastanawiam się które testy pisać, a które sobie być może odpuścić. Na razie zdecydowałem, że piszę, poza testami jednostkowymi modeli, testy funkcjonalne oraz integracyjne. Największą wagę przykładam jednak do tych ostatnich, bo pozwalają mi myśleć w kategoriach funkcjonalności oraz spodziewanych zachowań użytkowników. Zresztą wydają mi się też najbardziej naturalne w kontekście podejścia TDD/BDD. Tzn. wymyślam sobie jakiś scenariusz, piszę do tego testy integracyjne (RScpec, Capybara), a później dopisuję resztę kodu tak, by zrealizować założony cel. Po drodze oczywiście, kiedy muszę dodać kontroler albo nowy model, dopisuję pozostałe testy (funkcjonalne przede wszystkim jednak z myślą o nie najszybszych testach integracyjnych, które dzięki temu uruchamiam rzadziej).
Ostatnio na blogu Thoughtbota pojawił się jeszcze jeden wpis o testach. Również warty przeczytania
W railsach testy kontrolerów mogą być pisane w takim quasi-unitowym stylu a przynajmniej ja tak to robie. Generalnie moja motywacja jest prosta: chce miec “czyste” kontrolery i TDD przy tym pomaga.
Testy integracyjne sa definitywnie potrzebne, nawet jezeli coverage jedzie po tych samych LOC co w testach kontrolerow. Ja podobnie jak Jacek zaczynam od rspec+capy a jak juz mam jakis tam “szkielet” implementacji to zaczynam refactor, ktory bardziej opiera sie na testach unitowych. Czyli widze juz co sie musi dziac w kontrolerze wiec pisze sobie testy do tego i robie refactor. Dzieki temu w kontrolerach za duzo sie nie dzieje 
Ogolnie rzecz biorac kontrolery to straszna padaka w railsach takze nie dziwie sie ze ludzie nie lubia pisac do nich testow.
ps. @Tomash ^5
O, cześć Piotrek, nie wiedziałem że masz konto na forum! Czyżby sporo referrali stąd cię tu skierowało? 
Kontroler w każdym MVC to potencjalnie najbardziej syfiaste miejsce, bo najłatwiej się do niego wkłada logikę która wcale nie powinna tam być.
Hejka! Zawsze mialem tu konto 
Kukam tu od czasu do czasu.
Dzięki za odpowiedzi. Po zapoznaniu się z tym co mi podaliście mam kolejne pytanie. Testy integracyjne powinny być w folderze ‘integration’, ‘requests’, czy ‘features’?
rspec-rails przyjal konwencje, ze testy integracyjne moga byc w folderach “request”, “api” albo “integration”. Ja akurat testy integracyjne traktuje troszke inaczej, bo dla mnie sa to po prostu jakiekolwiek testy, ktore sprawdzaja integracje pomiedzy roznymi kompenentami (czyli nie sa unitowe). Wlasnie sobie uswiadomilem, ze w moim poprzednim poscie piszac “testy integracyjne” mialem na mysli testy, ktore sprawdzaja caly stack, czyli np. rspec feature tests czy cucumber scenarios. Dla mnie request tests maja sens tylko jak testujesz api.
Wydaje mi sie, ze ta cala zamota wynika z tego, ze w rails nigdy nie bylo koncepcji prawidziwych testow unitowych przez co testy modeli bardziej zalatuja testami integracyjnymi. Do tego testy integracyjne w swiecie rails to niby maja byc testy calego stacku czyli od requestu http przez kontroler do modeli i na renderowaniu konczac. Troche tego nie rozumiem, bo przeciez musi byc miejsce na testy integracyjne zgodnie z definicja, o ktorej wspomnialem powyzej. W tym momencie nie bardzo wiadomo gdzie takie testy ulokowac. np rspec automatycznie wstrzyknie ActionDispatch::Integration::Runner do examples znalezionych w spec/integration. To jest zgodne z konwecja rails oczywiscie ale dla mnie to jest bez sensu bo przeciez nie kazdy test integracyjny musi sprawdzac caly stack. Czesto chcesz po prostu sprawdzic jakis serwis ktory uzywa paru modeli itd.
Innymi slowy: ‘integration’ i ‘requests’ to jest jedno i to samo zgodnie z konwencja rails i rspec. ‘features’ to sa testy akceptacyjne uzywajac “feature” syntax w rspec i tam jest dostep do capybara. Trzeba tez pamietac, ze “feature” tests sa najwolniejszymi testami i powinno sie tam bardziej sprawdzac “happy paths” i integracje calego stacku.
1 Like