Czy BDD jest skalowalny dla średnich i dużych projektów?

22

Na każdej stronie internetowej, którą czytasz o BDD (Behaviour Driven Development), znajdziesz bardzo prosty miły przykład pokazujący, jak oczywiste i łatwe jest zdefiniowanie twoich wymagań. Ale próba wdrożenia tego procesu w dużym produkcie (nie w przykładzie kalkulatora) pokazała mi, że rzeczy mogą stać się (lub staną się) dość złożone i nieczytelne; szczególnie zmiana żądań w późniejszym terminie oznacza dużo pracy w celu poprawienia testów integracji w tym celu.

Zastanawiam się więc, czy BDD naprawdę jest tego warte? Czy rozwiązuje to problem, którego nie robią inne techniki!

DD
źródło
Szkoda, myślę, że ten problem jest dość konstruktywny, biorąc pod uwagę, że BDD jest ostatnio bardziej popularny.
DD
1
Jeśli ktoś z wystarczającą liczbą przedstawicieli może zasugerować ponowne otwarcie, byliby wspaniali.
DD
Chciałbym ponownie otworzyć, ale już zaakceptowałeś pierwszą odpowiedź ...
MattDavey
1
Zgodziłem się, ponieważ został zamknięty, więc wiedziałem, że nie ma już odpowiedzi, ale jestem naprawdę zainteresowany większymi raportami na ten temat, na razie go nie zaakceptuję
DD
2
ok świetnie :) Myślę też, że powinieneś trochę edytować pytanie. Myślę, że twoje pytanie dotyczy skalowalności BDD w dużych projektach. „Czy BDD naprawdę jest tak dobre” jest subiektywne, „Czy BDD dobrze skaluje się do dużych projektów” jest nieco bardziej obiektywne.
MattDavey

Odpowiedzi:

6

Myślę, że jednym z najlepszych zasobów na BDD jest książka specyfikacji według przykładów . Mówi wiele o tym, jak organizować testy BDD i jak powinny być pisane, aby nie powodowały tak wielu przeróbek, gdy zmieniają się wymagania.

Jeśli w twoich testach sprawy stają się skomplikowane lub nadmiernie skomplikowane, prawdopodobnie robisz coś złego. To samo dotyczy BDD i TDD. Pisanie dobrych testów jest trudne i na naukę potrzeba miesięcy.

Piotr Perak
źródło
3
TDD to nie to samo, testowanie predefiniowanej jednostki nigdy nie może uzyskać tego kompleksu, chyba że masz zbyt duże jednostki, które są zapachem kodu, ale testy integracyjne mają na celu przetestowanie interakcji między więcej niż jedną jednostką, całkowitą funkcjonalnością, co pozwala na zwiększenie jej złożoności liniowo w stosunku do wymagań, nadal nie można go rozbić na mniejsze części, ponieważ nie byłby to już test na integrację.
DD
Możesz załączyć niektóre skomplikowane testy BDD i widziałem, co można zrobić, aby je uprościć.
Piotr Perak
To nie jest takie proste, te, które tu mam, nie są w języku angielskim, musiałbym je przetłumaczyć, jeśli źle znajdę wymaganie, które z łatwością mogę przetłumaczyć na angielski, mogę go załączyć, ale kod nadal stanowi problem, który byłby za duży, aby dołączyć tutaj w jednym poście.
DD
Dlaczego zostało to zanegowane? Dałem wspaniałe zasoby, które pomogą OP rozwiązać jego problemy.
Piotr Perak
to nie byłem ja, dam +1, aby to zrekompensować, ale mogę to zrobić tylko w ciągu 14 godzin, ponieważ wykorzystałem wszystkie moje 30 głosów na dziś.
DD
5

Może pomóc zrozumieć, że BDD koncentruje się na rozmowach . BDD to tak naprawdę narzędzie analityczne, które zapewnia pewne testy regresji jako miły produkt uboczny.

W rozmowie korzystałem ze scenariuszy na wszystkich poziomach; od zidentyfikowania różnych interesariuszy, aby sprawdzić, czy wydanie prawdopodobnie zostanie dobrze przyjęte, po wypracowanie sposobu zachowania modułu lub klasy .

Jest kilka wskazówek i wskazówek, które mogę zasugerować, aby ułatwić to.

Jeśli nigdy tego nie robiłeś, to się zmieni.

Wszystko, co jest nowe w domenie lub firmie, może się zmienić. Możesz zdać sobie sprawę, że jesteś w tej przestrzeni, jeśli rozmawiasz przez scenariusze, kwestionując je , a firma mówi: „Och, nie jestem pewien”. To dobry znak, aby przestać próbować robić BDD i podkręcić coś, aby uzyskać szybszą informację zwrotną, aby pomóc firmie ustalić, czego chcą. Po ustabilizowaniu się pomysłów scenariusze można pisać retrospektywnie.

Wszystkie projekty mają dla nich coś nowego, bo inaczej byś ich nie realizował.

Jeśli zrobiłeś to wcześniej, to jest nudne.

Poza nowymi, różnicującymi aspektami, projekty zwykle mają pewne utowarowione aspekty, które są podobne do tych już wykonanych. Na przykład, gdybym produkował nowy telefon komórkowy, nadal musiałby wykonywać połączenia. „Zadzwoń” to tak dobrze znany scenariusz, że nie musielibyśmy przez niego rozmawiać. Podobnie rzeczy takie jak „logowanie”, a nawet „rejestracja użytkownika” są nudne.

Tam, gdzie to możliwe, używaj do nich bibliotek, a wtedy nie będziesz musiał pisać scenariuszy wokół nich. Również, czy inne bity pierwsze - mają już zalogowany użytkownik i pracy, co rejestrowanie on w za . Te obszary raczej się nie zmienią, więc możesz zrezygnować z ręcznego testowania.

Jeśli ktoś to zrobił wcześniej, pomocne może być omówienie scenariuszy.

Jest trochę między tym, gdzie mamy wymagania specyficzne dla domeny, co jest stosunkowo dobrze zrozumiane przez kogoś , a tym, gdzie prawdziwa niepewność dotyczy głównie zakresu, a nie rzeczywistego zachowania systemu.

Omawianie scenariuszy może pomóc zespołowi twórców odkryć zachowanie, skorzystać z wiedzy eksperta i zapewnić uchwycenie znanego, cennego zachowania.

W tym przypadku BDD działa najlepiej. Moja rada to napisanie najciekawszych scenariuszy na górze pliku funkcji (lub wiki, jeśli nie automatyzujesz) i usunięcie wszelkich scenariuszy, które są zduplikowane lub w rezultacie łatwe do wnioskowania.

Tam, gdzie to możliwe, używaj scenariuszy jako przykładów działania aplikacji . Na przykład, jeśli chcesz pokazać, jak działa sprawdzanie poprawności, pokaż kilka przykładów, w jaki sposób aplikacja pomaga użytkownikowi wypełnić formularz. Sprawdź, czy sprawdzanie poprawności jest rygorystyczne przy użyciu testów jednostkowych, które są znacznie łatwiejsze w utrzymaniu i szybsze w uruchomieniu.

Dalsza lektura

Jeśli jesteś tym zainteresowany, oto kilka rzeczy, które napisałem, które mogą pomóc.

BDD w dużej skali

Cynefin dla deweloperów , który bardziej szczegółowo omawia te trzy obszary

Moje slajdy z samouczkami , które są dla Ciebie miłe i opatrzone adnotacjami, i obejmują także cały stos.

Lunivore
źródło
Dziękuję za tę pouczającą odpowiedź, źle czytam załączone linki
DD
3

Jesienią zeszłego roku zbudowaliśmy dość skomplikowany projekt ( złożoność domen ) i mogę szczerze powiedzieć, że wprowadzenie do pracy BDD uratowało projekt. Widziałem silną korelację między złożonością domeny a korzyściami wynikającymi z BDD.

Pozwólcie mi usunąć jedno: testowanie złożonych reguł biznesowych jest trudne. Pytanie brzmi: czy chcesz spróbować zapamiętać wszystkie szalone scenariusze za każdym razem, gdy wprowadzasz zmiany, czy też chcesz, aby ta siatka bezpieczeństwa poinformowała Cię, gdy złamiesz specyfikację. Poświęć czas z góry i opracuj wszystkie scenariusze, zapisz je, a ostatecznie napisz wszystkie testy dla nich.

A kiedy wrócisz później, próbując zrozumieć sens, posiadanie tej sprawdzalnej specyfikacji jest ratowaniem życia.

Adrian Schneider
źródło
1

BDD to proces rozwoju oparty na TDD (Test Driven Development) Oto niektóre zalety i wady TDD zaczerpnięte z mojego osobistego doświadczenia:

  • TDD, upewnia się, że zakres jest dobrze zdefiniowany. W ten sposób najpierw projektujesz swoje przypadki testowe. W ten sposób ustaw oczekiwania na fragment kodu, który powinieneś napisać.
  • TDD to sposób na zabezpieczenie twojego kodu. Załóżmy, że piszesz prostą funkcję, a następnie dodajesz złożone warunki przełączania w tej samej funkcji. Jutro, jeśli ktoś chce zmodyfikować tę funkcję, może odnieść się do przypadku testowego. Jeśli chce zmienić twoją funkcję, musi także zmienić przypadek testowy (przez większość czasu). To pozwala mu zrozumieć, że za tym, co napisałeś, było uzasadnienie.
  • TDD pozwala na szybsze tworzenie oprogramowania. Każdy z nas napotkałby ten problem podczas kodowania. Zaczynamy od pomysłu. I powoli tracę to z oczu. W końcu umieszczamy niechciane fragmenty kodu do obsługi niektórych scenariuszy. W TDD z góry ustawiasz oczekiwania. W ten sposób ograniczasz się do oddalania się zbyt daleko od celu.
  • TDD pozwala wykryć ewentualne błędy, zanim projekt przejdzie do trybu online. Ma to głównie związek z jakością napisanych przypadków testowych.

Cons:

  • Początkowo TDD może być nieco trudne. Wiele osób nie rozumie pojęcia przypadku testowego napędzającego rozwój.
  • TDD, czasami może prowadzić do ogromnych wysiłków w zakresie konserwacji. Ma to związek z niechcianymi lub bezsensownymi przypadkami testowymi.
  • TDD należy przyjmować ze szczyptą soli. Żaden programista nie lubi spędzać czasu na testach napisanych przez kogoś innego. Rozszyfrowanie znaczenia zestawu testowego może czasami powodować poważny ból głowy.

Pracuję nad projektem zawierającym ponad 900 000 linii kodu. Nadal śledzę BDD. Jedną z najważniejszych rzeczy, które należy wziąć pod uwagę, jest liczba możliwych błędów, które możesz złapać wyłącznie z powodu przypadków testowych. Kilka lat później będziesz przeklinać przez BDD!

Ricketyship
źródło
2
Powinieneś bardziej szczegółowo omówić różnice między BDD i TDD oraz tym, gdzie wchodzi część DDD.
Benjamin Gruenbaum
1
@BenjaminGruenbaum Idealnie nie ma różnicy między BDD a TDD. Prawidłowe przestrzeganie BDD jest takie samo jak TDD! Więc nie widziałem żadnego powodu, aby wprowadzić różnicę jako część odpowiedzi. Dziękuję za sugestię!
Ricketyship
1
„TDD pozwala na szybsze tworzenie oprogramowania”. czy były jakieś badania potwierdzające to? Po prostu ciekawy. Chciałbym również wspomnieć, że przyspieszenie nie jest liniowe.
Den
2
@AlexandreMartins Hah, absolutnie! O wiele ważniejsze jest uznanie, że możesz mieć słabej jakości testy i scenariusze, niż udawanie, że wszystkie są dobre IMO.
Lunivore,
2
@Lunivore Tak, to mnie martwi w przypadku BDD / TDD. Przypadki testowe muszą być mocne. Niestety w społeczności programistów istnieje taki pogląd, że dopóki istnieją przypadki testowe, jest w porządku! Kiedyś widziałem przypadek testowy, w którym wiersz był wstawiany do tabeli za pomocą instrukcji sql i to samo stwierdzano w następnym kroku! Czy programista próbował przetestować funkcjonalność Oracle ?!
Ricketyship