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

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 )?

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.

„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).

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ą.

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.

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.

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

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

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.

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.