Cucumber testowanie istnienia hasłą

Cześć, mam drobny problem. Mając dla outlines następujący kod:

Scenarios: without presence | username | email | password | password_conf | message | | | user@example.com | secret | secret | Username can't be blank | | testuser | | secret | secret | Email can't be blank | | testuser | user@example.com | | secret | Password can't be blank | | testuser | user@example.com | secret | | Password confirmation can't be blank |
Dla pierwszych dwóch przypadków naturalnie wyrzuca błąd zanim dodam walidacje, natomiasat dwa ostatnie przechodzą bez problemu, mimo że walidacji nie ma.
Jakieś wskazówki jak rozwiązać problem?

Pozdrawiam :slight_smile:

Jesteś pewien, że nie ma? Czego używasz do uwierzytelniania? Devise?

[quote=Vayneyks]Cześć, mam drobny problem. Mając dla outlines następujący kod:

Scenarios: without presence | username | email | password | password_conf | message | | | user@example.com | secret | secret | Username can't be blank | | testuser | | secret | secret | Email can't be blank | | testuser | user@example.com | | secret | Password can't be blank | | testuser | user@example.com | secret | | Password confirmation can't be blank |
[/quote]
Ołaaaa, panie!
Wiem, że pytanie było o co innego, ale powiem Ci radę od serca - nie idź tą drgoą!!

Czemu to w ogóle jest testowane w cucumberze? Przecież to jest ogromna strata czasu, jeśli chodzi o wykonanie testów i znikoma szansa na wyłapanie błędu, który można wyłapać przez testy unitowe.

problem został rozwiązany ; )

@sarniak - a czemu testy unitowe? A może sam rspec? ; ) Nie ukrywam - nie lubię test unit i wolę BDD.
Albo zróbmy od razu flame: po co w ogóle cucumber? Czy właśnie nie po to, by pisać testy integracyjne i różne przypadki?

@tiwi: sorcery. Rozwiązanie: w dokumentacji jest page.has_content?(text), natomiast działa przy page.has_content?(text).should == true.

Dzięki wielkie za odpowiedzi :slight_smile:

Odsyłam do http://en.wikipedia.org/wiki/Unit_testing

Też używam rspeca i piszę w nim testy jednostkowe. Niekoniecznie musi się nazywać test unitem - to tylko konwencja.

Jeśli nie widzisz nic złego w tym, żeby odpalać do prostych walidacji n scenariuszy cucumbera, to jak najbardziej cucumber może być właśnie po to. Ja nie zamierzam flejmować, zrobisz jak uważasz :>

Widzę, w ogóle jestem Ci bardzo wdzięczny za bezpośrednią odpowiedź, bo doczytałem sobie i przemyślałem dzisiaj - i poniekąd zgadzam się z Tobą.
Raczej dąże do tego, czy pisanie test unitami kodu do sprawdzenia różnych przypadków nie jest mało eleganckie? I ponawiam pytanie - po co cucumber? Czy tylko jako kod dla klienta?

Pozdrawiam :slight_smile:

[quote=Vayneyks]Widzę, w ogóle jestem Ci bardzo wdzięczny za bezpośrednią odpowiedź, bo doczytałem sobie i przemyślałem dzisiaj - i poniekąd zgadzam się z Tobą.
Raczej dąże do tego, czy pisanie test unitami kodu do sprawdzenia różnych przypadków nie jest mało eleganckie? I ponawiam pytanie - po co cucumber? Czy tylko jako kod dla klienta?[/quote]
Ok, rozwinę trochę :wink:

Zaczynałem z cucumberem gdy to było bardzo modne i wszyscy się zachwycali tym, że można pisać po angielsku. W praktyce wyglądało to tak. Kroki robiły się coraz bardziej zagmatwane, coraz więcej było tabelek do inicjalizacji danych, tabelek do różnych scenariuszy. Klient tego nie czytał, a to jest dla mnie jedyna zaleta babrania się w pisaniu kroków w ludzkim języku, które i tak trzeba obkodować.

Ale to tylko odnośnie cucumbera, można się zgodzić lub nie. Ja wolę pisać normalnie w rspecu i używać pod spodem capybary - wszystko pięknie działa, aczkolwiek co kto lubi. Nie ma co się spierać o takie rzeczy.

Problemy z testami integracyjnymi w takim wydaniu są na kilku poziomach:

  1. Czas wykonywania. Wyobraź sobie BDD z takim test suitem. Przy malutkiej aplikacji to jeszcze możliwe, ale ile tak naprawdę rozwijałeś małych aplikacji?
  2. Niezawodność. Pół biedy, jeśli nie ma tam jsów i wykonujesz to bez zaprzęgania selenium, czy wręcz przeglądarki. Bo jeśli tak, to zwiększasz znacznie szansę, że coś się zawiesi. Jeśli puszczam testy integracyjne i coś padnie to mogę być niemal pewny, że coś zepsułem, albo test jest źle napisany. W cucumberze czasem zdarzy się, że driver się zawiesi i nie odpowiada.
  3. Prostota pisania.

I teraz pytanie najważniejsze. Co tak naprawdę testujesz? Testujesz, czy wykonają się walidacje, za co jest odpowiedzialny model. Ok, jest tu jeszcze kilka spraw, jak pokazanie się informacji o błędach, ale to można zrobić jednym przypadkiem, gdzie masz wszystkie pola błędne, więc tutaj powinien wystarczyć jeden test na poprawne dane, jeden na niepoprawne.

W przypadku rejestracji taka ostrożność jest wytłumaczalna, ale na dłuższą metę i w większości innych przypadków jest to moim skromnym zdaniem strzelanie sobie w stopę.

Dlatego jak zawsze wszystko zależy :>, tylko jakoś tak mi się zapala czerwone światło, gdy widzę takie rzeczy ;).

Dziękuję bardzo za odpowiedź :slight_smile: Przepisałem kod z cucumbera do testów integracyjnych w rspecu i rzeczywiście - szybciej i wszystko w jednym miejscu :slight_smile:

Pozdrawiam :slight_smile:

PS: Temat można zamknąć.