RSpec vs Cucumber (historie RSpec) [zamknięte]

136

Kiedy powinienem używać specyfikacji dla aplikacji Rails, a kiedy Cucumber (dawniej rspec-story)? Oczywiście wiem, jak zarówno działają, jak i aktywnie używam specyfikacji. Ale nadal dziwnie jest używać Ogórka. Mój obecny pogląd na ten temat jest taki, że wygodnie jest używać Cucumber podczas wdrażania aplikacji dla klienta i nie rozumiem jeszcze, jak cały system ma działać.

Ale co, jeśli robię własny projekt? Przez większość czasu wiem, jak współdziałają elementy systemu. Muszę tylko napisać kilka testów jednostkowych. Jakie są możliwe sytuacje, w których potrzebowałbym wtedy ogórka?

I jako odpowiednie drugie pytanie: czy muszę pisać specyfikacje, jeśli piszę historie o ogórkach? Czy nie byłoby to dwukrotne przetestowanie tej samej rzeczy?

snitko
źródło
12
Jak to każdy pojedynczy [Zamknięty] pytanie, które spotykam jest zamknięta, ponieważ „nie konstruktywne” Bill Lizard I jednocześnie pytanie jest upvoted wiele razy!?! czego mi brakuje ?
Ashkan Kh. Nazary
4
W pełni się zgadzam. Nadal nie wiem, gdzie zadawać pytania typu „jakie są najlepsze praktyki XXX”.
Dziekan
3
Zgadzam się, przez cały czas napotykam dobre pytania z wnikliwymi, pomocnymi odpowiedziami na SO, które zostały zamknięte z tego czy innego powodu.
Russell Silva
Znalazłem to pytanie w 2017 roku, ponieważ nadal jest aktualne i nadal jest świetne, ze świetnymi odpowiedziami. Nie zachęca to również do wyrażenia opinii, ponieważ ramy, o których mowa, zostały zaprojektowane przez w większości te same osoby dla dwóch zupełnie różnych problemów ... ale potrzebujesz trochę wiedzy, aby to wiedzieć.
Lunivore

Odpowiedzi:

114

Jeśli jeszcze tego nie zrobiłeś, możesz przeczytać doskonały artykuł Dana Northa „ What's in a Story? jako punkt wyjścia.

Mamy dwa główne zastosowania opowieści o ogórku. Po pierwsze, ponieważ forma historii jest bardzo specyficzna, pomaga skupić się na wyrażaniu przez właściciela produktu funkcji, które chce stworzyć. Jest to „symbol do rozmowy” wykorzystania historii i byłoby cenne niezależnie od tego, czy zaimplementowaliśmy je w kodzie. Po drugie, kiedy proces przebiega na tyle dobrze, że mamy kompletne historie, zanim zaczniemy pisać artykuł (bardziej ideał, do którego dążymy niż codzienna rzeczywistość), masz jasno określone kryteria akceptacji i wiesz dokładnie, co i jak dużo do zbudowania.

W naszej pracy z Railsami historie Cucumber nie zastępują testów jednostkowych rspec. Te dwie rzeczy idą w parze. W praktyce testy jednostkowe kierują rozwojem modeli i kontrolerów, a historie kierują rozwojem widoków (zwykle nie piszemy rspec dla naszych widoków) i zapewniają dobry test aplikacji jako całości z poziomu perspektywa użytkownika.

Jeśli pracujesz solo, aspekt komunikacji może nie być dla Ciebie interesujący, ale testy integracyjne, które otrzymujesz od Cucumber, mogą być. Jeśli korzystasz z webrat , pisanie ogórka może być szybkie i bezbolesne w przypadku większości podstawowych funkcji.

Abie
źródło
6
Łączysz dwie odrębne kwestie; 1) czy dobrze jest przeprowadzić testy integracyjne i akceptacyjne oraz 2) czy ogórek jest dobrym narzędziem do zapisywania tych testów. Po 1 - tak, to zdecydowanie dobry pomysł. W przypadku 2 rzadko jest bardziej wydajne dla zespołu programistów pisanie testów w języku o tak dużej liczbie nieokreślonych kierunków, kiedy można napisać bardzo czytelne testy integracji i akceptacji w rspec i kapibara (lub - broń Boże, moglibyśmy zbadać standardową bibliotekę Rubiego - test / unit lub minitest wraz z kapibarą). Zobacz poniższy post, do którego prowadzi Jack Kinsella.
Graham Ashton
Całkowicie się z tobą zgadzam Abie! Integracja ogórka jest niezbędna!
dpapadopoulos
26

Pomyśl o tym jako o cyklu:

Napisz swoją funkcję Ogórka, a następnie podczas opracowywania elementów dla tej funkcji napisz specyfikacje, aby ukończyć poszczególne komponenty. Kontynuuj wypełnianie specyfikacji, dopóki nie napiszesz wystarczającej liczby funkcji, aby funkcja mogła przejść, a następnie napisz kolejną funkcję.

Josiah Kiehl
źródło
1
Jest bardzo ładny przykład cyklu Outside-in BDD .
rdamborsky
21

Uważam, że używanie Ogórka w większości sytuacji jest złym pomysłem ze względu na koszty produktywności, jakie nakłada na ciebie jego składnia. Pisałem obszernie na ten temat w Dlaczego przejmować się testami ogórka?

Jack Kinsella
źródło
1
Przeczytałem Twój artykuł i jako fan ogórka muszę powiedzieć, że zgadzam się z wieloma punktami, które przytaczasz w swoim artykule. Chociaż nadal uważam, że ogórek jest dobrym sposobem na sformalizowanie testów i uczynienie ich czytelnymi dla osób postronnych.
huug
1
Jack - fantastyczny post. Dziękuję bardzo za napisanie tego, zaoszczędziłeś mi kłopotów z robieniem tego samemu.
Graham Ashton
3
huug - To może być dobry sposób na pokazanie testów „osobom z zewnątrz”, ale pokaż mi nietechnicznego członka zespołu, który chce przeczytać testy, a ja pokażę ci zespół, który marnuje swój budżet. Nie pracowałem jeszcze z nietechnicznym członkiem projektu, który chciałby tracić czas na czytanie testów. Nie wiem, może mam szczęście ...
Graham Ashton
Głosowano w dół. Uważam, że opisywanie funkcji użytkownika terminami użytkownika jest przydatne dla mnie, jako programisty, niezależnie od tego, czy użytkownicy kiedykolwiek czytali moje historie o Ogórkach. Dlatego używam Cucumber we wszystkich moich projektach i zachęcam innych, aby robili podobnie.
Marnen Laibow-Koser
8

Historia ogórka jest raczej opisem ogólnego problemu, który rozwiązuje Twoja aplikacja, a nie tym, czy działają poszczególne fragmenty kodu (tj. Testy jednostkowe).

Jak opisuje Abie, jest to prawie lista wymagań, które aplikacja powinna spełniać i jest bardzo pomocna w komunikacji z klientem, a także jest bezpośrednio testowalna.

Dave Glassborow
źródło
2
Dokładnie. Ogórek opisuje sposób użycia Twojej aplikacji. Np. „Klikam tutaj i spodziewam się takiego lub innego wyniku”. Specyfikacje są bardziej na poziomie „modelu”. Na przykład, kiedy wywołuję te metody z takimi a takimi parametrami, oczekuję, że zwróci ten wynik.
Ariejan
6

W dzisiejszych czasach możesz używać rspec z Capybara i Selenium Webdriver i uniknąć konieczności budowania i utrzymywania wszystkich parserów historii Cucumber. Oto, co bym polecił:

  1. Napisz swoją historię
  2. Używając RSpec, stworzyłbym test integracji, np. Spec / integrations / socks_rspec.rb
  3. Następnie stworzyłbym test integracji, który zawierałby nowy opis i blok dla każdego scenariusza
  4. Następnie wdrożyłbym minimalną funkcjonalność wymaganą do uzyskania testu integracji, a cofając się głębiej (do kontrolerów i modeli itp.), Dodałbym TDD na kontrolerach i modelach.
  5. Po utworzeniu kopii zapasowej test integracji powinien zakończyć się pomyślnie i możesz kontynuować dodawanie kroków do testu integracji
  6. powtarzać

Należy jednak zauważyć, że testy kontrolera i integracji pokrywają się, co może nie być konieczne, dlatego należy zachować najlepszą ocenę, aby nie marnować czasu.

Poza tym, gdy już znajdziesz swój rytm, najbardziej sprawi ci przyjemność rozwijanie się przy użyciu BDD, do tego czasu nie czuj się winny, jeśli nie czujesz, że robisz to doskonale i nie przemyślaj tego. Poradzisz sobie świetnie!

PeppyHeppy
źródło
2

Ale co, jeśli robię własny projekt? Przez większość czasu wiem, jak współdziałają elementy systemu. Muszę tylko napisać kilka testów jednostkowych. Jakie są możliwe sytuacje, w których potrzebowałbym wtedy ogórka?

Nadal potrzebujesz ogórka. Potrzebujesz go do udokumentowania tego, jak działa system, i potrzebujesz go, aby upewnić się, że nie zepsujesz funkcjonalności podczas zmiany.

Innymi słowy, potrzebujesz opowieści o ogórkach z tych samych powodów, co testy jednostkowe - po prostu działają one na wyższym poziomie abstrakcji.

Marnen Laibow-Koser
źródło
2
Nie powiedziałbym, że Cucumber jest niezbędny, ale z pewnością powinieneś mieć jakieś testy integracyjne, ponieważ testy jednostkowe są zwykle używane tylko do testowania klas w izolacji.
Andy Waite
1
Dobrze. W większości przypadków Cucumber to najprzyjemniejszy sposób pisania testów integracyjnych.
Marnen Laibow-Koser