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

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!

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.

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.

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.

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!