Jakie są różnice między frameworkami BDD dla języka Java? [Zamknięte]

121

Jakie są zalety i wady każdego frameworka Behavior Driven Development (BDD) dla języka Java?

Znalazłem niektóre z nich tutaj , na przykład.

Czy ma sens używanie frameworka BDD, skoro już używam biblioteki do próbowania (np. Mockito )?

user68109
źródło
proszę zdefiniować BDD lub link do definicji
Jason S
4
BDD = Rozwój oparty na zachowaniu
Vinnie,
4
Szkoda, że ​​nie otrzymałem więcej odpowiedzi!
Pablo Fernandez
dla Cuke4Duke przeczytaj cucumber-jvm w mojej bounty. Mam jeszcze 22 godziny na przyznanie nagrody ...
Sam Hasler,

Odpowiedzi:

99

Właśnie skończyłem porównywać trzy frameworki BDD dla Javy. Oczywiście moje odkrycia mają dość krótki termin przydatności do użycia.

Concordion

  • Bardzo elastyczny
  • Bardzo ładny wynik raportu
  • Niezła struktura wtyczki
  • Słabo udokumentowane. Musiałem przeczytać źródło, aby to rozgryźć (na szczęście jest to wyjątkowo dobra jakość).
  • Wydawało się, że mocowania będą ściśle powiązane z kodem HTML.

EasyB

  • Bardzo płytka krzywa uczenia się (nawet dla nie-Groovy Developerów)
  • Niezwykle wydajna integracja DBUnit
  • Najwyraźniej brak obsługi parametrów (prowadzi do bardzo niejasnych historii lub powielania tekstu i kodu (edycja: w rzeczywistości istnieje, ale dokumentacja była bardzo dobrze ukryta).
  • Historia i kod są ze sobą ściśle powiązane (ten sam plik)
  • Bardzo podstawowy wynik raportu
  • Nie można uruchomić wtyczki IntelliJ
  • Nieaktywna społeczność (wydaje się, że wtyczka Maven była zepsuta przez trzy miesiące - niewiele przykładów kodu do wykorzystania)

JBehave

  • Niezwykle wydajny i elastyczny (np. Redukcja płyty kotła poprzez kompozycję kondygnacji jako warunek wstępny)
  • Obszerna (jeśli jest fragmentaryczna) dokumentacja i przykłady
  • Rozległe (choć przytłaczające) wsparcie dla różnych platform i środowisk
  • Doskonałe oddzielenie plików historii od kodu
  • Wygląda na to, że społeczność jest całkiem aktywna i ma dużo więcej przykładów i dyskusji na ten temat w sieci.
  • Dość stroma krzywa uczenia się (zajęło mi 3-4 razy więcej zrozumienia niż Concordion / EasyB)

Nie miałem okazji wypróbować Cuke4Duke of JDave tak, jak bym chciał, ale prawdopodobnie będę teraz naciskać na JBehave.

Caoilte
źródło
4
+1: zdecydowanie najlepsza odpowiedź tutaj. Dodawanie linków.
haylem
35

„wady i zalety” mogą oznaczać różne rzeczy dla różnych ludzi. Zwykle patrzę na

  • działalność deweloperska , np. czy prawdopodobne są nowe wydania lub czy ostatnie wydanie ma 2 lata.
  • dojrzałość , np. jak długo to trwa, czy są dostępne tutoriale, a może nawet książki. (Nie czytam tych książek, to tylko znak adopcji.)
  • obsługa narzędzi , np. czy jest wtyczka Eclipse, obsługa Ant itp
  • rozmiar zależności , nie lubię frameworków, które mają wszystko własne. np. Sam chcę wybrać mój model do kpiny.
  • rodzaj licencji , jest to dla mnie ważne ze względu na warunki prawne w firmie, w której pracuję.
  • zgodność z powiązanymi narzędziami , np. czy używa języka Gherkin, czy nie.

Z niektórych frameworków przyjrzałem się

  • Instynkt zły : ostatnia aktywność marzec 2010, dobra : licencja ASF
  • JDave zły : pochodzi z dopasowaniami i próbami, dobrze : ostatnia aktywność styczeń 2011, licencja ASF
  • easyb zły : ostatnia aktywność październik 2010, nie jestem pewien : używa Groovy. To może być w porządku, ale w moim przypadku byłby problem z adopcją.
  • beanspec zły : tylko jedna wersja w 2007 roku, ta jest martwa
  • bdoc zły : ostatnia aktywność Styczeń 2010, nie jestem pewien : wygląda na to, że idziemy w drugą stronę, tworząc raport z kodu.
  • spock zły : może trochę ekstremalny, to jest kompletny framework testowy, nie tylko BDD, dobrze : bardzo aktywny, bardzo fajny.
  • jbehave , "matka" wszystkich BDD w Javie, zły : bardzo potężny = złożona, niekompatybilna licencja (dla mnie), jest dostarczany z prawie każdą biblioteką testową i wieloma innymi, dobrze : oparty na RSpec, a zatem kompatybilny, wtyczki eclipse, integracja z maven , bardzo aktywna społeczność
  • ginkgo4j , framework BDD dla Java również oparty na RSpec Ruby'ego, ale używający Java lambda (zamiast adnotacji), aby umożliwić tworzenie wysoce kontekstowych, bardzo czytelnych testów. Prosty. Bardzo potężny. Licencja Open Source Apache 2.

Odnośnie makiet: Zdecydowanie potrzebujesz również frameworka do kpiny. Frameworki BDD po ​​prostu pomagają w pisaniu specyfikacji, ale niektóre testy będą wymagały mocków lub kodów pośredniczących, szczególnie. podczas projektowania z góry na dół (od przeglądu po szczegóły).

Peter Kofler
źródło
jbehave posiada 3-klauzulową licencję BSD: jbehave.org/license.html . Nie jestem pewien, dlaczego ktoś miałby się z tym kłócić?
Ramon
Ramon, chodzi o zależności. Dużo ich. Może wszystkie z nich to Apache lub BSD, nie zawracałem sobie głowy sprawdzaniem.
Peter Kofler,
Dobry zaktualizowany wykaz BDD Ramki behaviour-driven.org/Implementations
Paul Verest
Możesz dodać JGiven do tej listy.
Jan Schaefer
20

Jaki jest najlepszy framework BDD do użycia z Javą? Czemu? Jakie są wady i zalety każdej platformy?

Oto interesujący link na temat testów akceptacyjnych opartych na Concordion vs. Cucumber i Javie

Znalazłem tutaj kilka z nich, ale nie jestem pewien, który wybrać.

Naprawdę, spójrz na wspomnianą powyżej.

Czy ma sens używanie frameworka BDD, skoro już używam biblioteki do próbowania (np. Mockito)?

Krótka odpowiedź: tak, zdecydowanie. W rzeczywistości testy akceptacyjne przy użyciu frameworka BDD i testy jednostkowe w izolacji przy użyciu pozorowanych obiektów są tak różne, że tak naprawdę nie rozumiem tego pytania. Testy akceptacyjne to testy czarnoskrzynkowe. Testy służą do sprawdzenia, czy funkcja biznesowa działa i są idealnie napisane przez analityka biznesowego. Testy jednostkowe w izolacji przy użyciu makiet to testy białoskrzynkowe, testy służą do sprawdzenia, czy jednostka działa i są napisane przez programistów. Oba są przydatne, ale mają zupełnie inne przeznaczenie. Innymi słowy, użycie Mockito w ogóle nie zastępuje frameworka BDD, a odwrotność jest również prawdą.

Pascal Thivent
źródło
To, co powiedziałeś, nie jest złe, ale to nie znaczy, że nie możesz pisać testów jednostkowych w stylu bardziej przyjaznym dla BDD. Nie jest to przykładowa specyfikacja, ale też nie jest to bezwartościowa funkcja. docs.mockito.googlecode.com/hg/org/mockito/BDDMockito.html
cwash
7

Początkowo robiłem BDD z prostym jUnitem, ale ostatnio patrzyłem na JDave, ponieważ to prawie 1: 1 do tego, co robiłem z jUnit. Działa również na jUnit, więc działa już na Eclipse i jest również łatwy w konfiguracji do pracy z systemami ciągłej integracji, takimi jak Hudson. Nie mogę tego porównać z innymi, ale moje doświadczenia z JDave są do tej pory dobre.

Och, i to nigdy nie jest głupi pomysł, aby używać kpiny! Nie są one związane konkretnie z TDD / BDD, ich celem jest ogólne zmniejszenie ciężaru testowania.

Esko
źródło
6

Wow, widzę, że temat jest gorący, dużo dobrych odpowiedzi ...

Pomijając ironię, niedawno odkryłem BDD i uznałem tę koncepcję za interesującą. Hej, to zmusza do napisania testów ... i specyfikacji! Choć może się to wydawać zaskakujące, tego ostatniego może brakować w niektórych projektach ... Lub po prostu brakować precyzji, którą wymusza na BDD.

Artykuł Behavior Driven Development podsumowuje koncepcję i linki do kilku dobrych artykułów (takich jak ten napisany przez Andrew Glovera). Co więcej, na temat tego wątku zawiera dość obszerną (jak sądzę) listę frameworków BDD, z których wiele jest przeznaczonych dla Javy.
Nie rozwiązuje problemu wyboru frameworka, ale przynajmniej ułatwi wyszukiwanie ...

Ponieważ BDD w dużym stopniu opiera się na czytelności kodu testowego, przypuszczam, że dobrym kryterium wyboru jest przejrzenie krótkich wycieczek / samouczków i sprawdzenie, który z nich wydaje się bardziej pasować do Twojego stylu. Innymi kryteriami może być fakt, że framework wykorzystuje narzędzia, które znasz (testy jednostkowe, mockowanie), użycie z IDE i tak dalej.

PhiLho
źródło
4

Wypróbowałem Cucumber-JVM (wcześniej opracowany jako Cuke4Duke). Używa Gherkin DSL do specyfikacji, przechowywanego jako zwykły tekst.

Przykład Cucumber-JVM w Eclipse 4.2

Można go uruchomić jako test JUnit. Tak więc jedynym problemem związanym z rozpoczęciem korzystania z niego jest umożliwienie ludziom biznesu lub kierownikowi produktu odczytu / zapisu funkcji w Źródłach.

Wyniki

Paul Verest
źródło
3

Mój zespół od jakiegoś czasu używa JBehave . Używa zwykłych plików tekstowych do przechowywania specyfikacji. Każdy krok (określony, kiedy, to) jest następnie wykonywany za pomocą określonej metody, która może wyodrębnić parametry z kroku. Scenariusze mogą mieć wcięcia i być dobrze sformatowane, co bardzo pomaga, jeśli klienci chcą je zweryfikować.

Są też pewne problemy. Przerzuciliśmy się na Javę 6. Czasami niektóre kroki scenariusza są ignorowane podczas wykonywania. Może to spowodować wiele problemów ze znalezieniem przyczyny błędu.

Boris Pavlović
źródło
2
@Boris Czy Twoim problemem może być to, że PENDING kroki liczą się jako pomyślne (domyślne zachowanie), a nie jako nieudane? Jeśli to twój problem, możesz skonfigurować PendingErrorStrategy: jarvana.com/jarvana/view/org/jbehave/jbehave-core/2.2.1/…
JeffH
3

Mój zespół z powodzeniem korzystał z JBehave - przenieśliśmy się do niego po użyciu EasyB i okazało się, że łatwiejsze w obsłudze są zwykłe pliki tekstowe.

Matt Green
źródło