Po dłuższej przerwie na naukę samego ruby wracam do oswajania RoR i mam pytanie.
Zakładając posiadany zestaw narzędzi rails 3.1, rspec + capybara + capybara webkit driver jak zabrać się za poprawne pisanie przy użyciu BDD?
Przy pomocy tych narzędzi mogę testować:
model (w izolacji)
kontrolery (w izolacji)
widoki (w izolacji)
pełne ścieżki (integracyjnie)
Teraz załóżmy, że jest do napisania funkcjonalność X.
Czy mój poniższy tok postępowania jest ok?
testy i implementacja UI (test widoku w izolacji)
napisanie testu integracyjnego danego scenariusza (test integracyjny ścieżki) -> nie będize przechodził praktycznie do samego końca
test i implementacja kontrolera w izolacji
test i implementacja modelu w izolacji
Teraz dopiero powinien się zazielenić test requesta.
Czy to ma rączki i nóżki, czy są inne praktyki na to?
Ostatnio staram się ograniczać ilość pisanych testów do niezbędnego minimum. Podobnie jak w przypadku budowania kodu aplikacji stosuje się DRY, tak samo należałoby postępować w przypadku testów. Próbuję więc nie powtarzać się w testach i nie pisać ich “na siłę”.
Nie wiem, ale skoro rspec-rails to potrafi to pewnie ktoś to robi. Wg mnie test widoku tutaj trochę nie pasuje, bo tak jak mówisz powinno zaczynać się od integracyjnego (tak to w Javie działało). Integracyjny jest w stanie sprawdzić poprawność widoku pośrednio, a złożone problemy typu kod JS i tak testuje się osobno, np. jakimś Jasmine czy innym podobnym narzędziem.
@Matthias, fakt - może pomóc. Chociaż ostatnio naczytałem się o sposobie na “Fast Rails Tests” który proponuje Corey Haines i rozkminiam to wszystko. Jako że mam Javową głowę nadal, to potrzeba trochę czasu na ogarnięcie tych wszystkich innych koncepcji.
Nie wiem, ale skoro rspec-rails to potrafi to pewnie ktoś to robi. Wg mnie test widoku tutaj trochę nie pasuje, bo tak jak mówisz powinno zaczynać się od integracyjnego (tak to w Javie działało).[/quote]
Nie wiem, gdzie przeczytałeś o tym, że powinno zaczynać się od testu widoku. Zaczyna się od testu integracyjnego.
