Witam. Wymyśliłem sobię , że będę dla każdej możliwej roli testować każdą akcję w każdym kontrolerze pod kątem tego czy aby na pewno dostane access denied wtedy kiedy trzeba.
Pomysł na jaki wpadłem z początku mi się spodobał , zanim go zaimplementowałem miałem mase problemów wynikających z całkowitego braku doświadczenia z controller testami.
Doszedłem jednak do momentu kiedy zaczeły się takie schody , że
czas zastanowić się nad tym czy cały pomysł nie powinien znaleźć się w koszu
jeżeli jednak nie jest głupi to zapytać o kilka problemów jakie napotkałem i ew. o możliwości refaktoringu.
Do rzeczy:
Przykładowy controller test:
Mój helper:
Idea jest taka:
W tescie kontrolera definijujemy liste akcji (metoda, akcja, ewentualne parametry do linku) , oraz liste ról - true/false (czy user z daną rolą może wejsc w tą akcję)
Iterujemy po tych listach dla kazdej roli wykonujac kazda z tych akcji i sprawdzamy czy cancan przekierował nas do home#access_denied
rescue_from CanCan::AccessDenied do |exception|
redirect_to access_denied_url, :alert => I18n.t(‘general.access_denied’)
end
1sze schody zaczynają się już w podstawowych crudowych akcjach edit/show/destroy gdzie dostajemy errora gdy próbujemy działać na nieznalezionym dokumencie.
Wystubowałem więc Document.find tak aby znajdowało zawsze dokument . Ale już gdy dodałem kolejną bardziej skomplikowaną akcję zaczeły się większe schody , ponieważ tam już mam params[:a][:b] i oczywiscie undefined method `[]’ for nil:NilClass
Czy jeżeli uważacie, że pomysł nie jest głupi macie jakieś pomysły jak możnaby obejść tego typu przypadki? Czy może jednak dla bardziej złożonych akcji pisać oddzielne testy stubujące co trzeba i wywoływać tylko funkcję check_privilages ?
Z góry dziekuje za pomysły/ konstruktywna krytykę / hejt / trolling na poziomie ;]
Jeśli na prawdę tego nie potrzebujesz to odradzałbym Ci testowanie uprawnień w ten sposób, bo liczba możiwych kombinacji bardzo szybko robi się ogromna. To co przetestowałbym na Twoim miejscu jeśli używasz CanCan to testy jednostkowe dla klasy Ability. Dodatkowo po stronie kontrolera sprawdzałbym już wtedy tylko czy masz dobrze poustawiane metody do autoryzacji.
Test jednostkowy do Ability, a potem już tylko klikające po aplikacji testy integracyjne, np. Capybara, które pokrywają przynajmniej większość typowych przypadków.
Inna sprawa, z mojego doświadczenia wynika, że pisanie testów jednostkowych do kontrolerów rails jest dość upierdliwe i raczej je pomijam. Wyjątkiem są jedynie testy do API. Po prostu dobrze napisane testy integracyjne powinny zapewnić duże pokrycie do kodu kontrolerów.
Czyli przekaz taki ze jak mam 10 roli to w jednostkowym tescie sprawdzic wszystkei czy dobrze ustawione w ability, a w akceptacyjnych jeden test dla roli która może wejsc byle której i jeden test dla roli która nie wejdzie i w zasadzie mam wtedy otestowane wszystko. Racja ;] Kolejny raz chciałem się poduczyć controllerowych testów ale znowu okazały się nie potrzebne ;p
Użyteczność testów do kontrolerów nie jest taka zła… jak się ja porówna do żyteczności testów do widoków np. view speci
Wydaje mi się, że takie podejście będzie miało duże “business value”, tj. jednostkowe do ability + integracyjne do głównych przypadków.
Jeśli np. tester wykryje buga, to dopisujemy test integracyjny do danego przypadku, rozszeżamy jednostowe itp.
Moim zdaniem wszystkiego się nie da dobrze przetestować, a jak bardzo się staramy to zostajemy z tonami ciężkich do utrzymania testów.
