Jak korzystać z testów jednostkowych podczas korzystania z BDD?

Próbuję zrozumieć BDD. Przeczytałem kilka artykułów i jak zrozumiałem, BDD to „następny krok” od TDD. Mówię to, ponieważ uważam, że oba są bardzo podobne, i jak mogłem przeczytać w tym artykule , BDD narodziło się jako ulepszenie z TDD. Świetnie, naprawdę podoba mi się ten pomysł.

Jest jedna praktyczna kwestia, której nie rozumiem, pomyślał: istnieje plik .feature, w którym BA zapisze wszystkie oczekiwane zachowanie, w którym zachowałby się system. Jako licencjat nie ma pojęcia, jak budowany jest system, więc napiszemy coś takiego:

+ Scenariusz 1: konto jest zasilone +

Biorąc pod uwagę, że konto jest zasilone

Karta jest ważna

A dozownik zawiera gotówkę

Gdy klient zażąda gotówki

Następnie upewnij się, że konto jest obciążone i upewnij się, że wypłacono gotówkę

I upewnij się, że karta została zwrócona

Ok, to świetnie, ale istnieje wiele części systemu, które będą ze sobą współpracować, aby mogło się to zdarzyć (pomyśl o Konto obj., Dozownik obj, Klient obj. I tak dalej). Dla mnie wygląda to na test integracyjny.

Chciałbym przeprowadzić testy jednostkowe. Jak przetestować kod sprawdzający, czy w dozowniku są pieniądze? Lub że gotówka jest wydawana? Czy konto jest obciążane w razie potrzeby? Jak łączyć testy jednostkowe z testami „BA Created”?

Rozwój oparty na zachowaniu i rozwój oparty na testach są komplementarne, ale nie zastępują się nawzajem.

Jak „zachowuje się” aplikacja jest opisana w Testach akceptacyjnych, które według BDD byłyby funkcjami i scenariuszami napisanymi w Cucumber.

Szczegółowe informacje o tym, jak działa każdy mały komponent, opisano w Testach jednostkowych. Wyniki testów jednostkowych wspierają scenariusze napisane w Ogórku.

Wyobraź sobie proces budowy samochodu.

Po pierwsze, zespół produktowy wymyśla swoje pomysły i ostatecznie sprowadza je do scenariuszy użycia:

Scenario: Starting the car
    Given I am standing in front of the drivers door
    When I open the door
    Then the door should lift up DeLorean-style (yeah, baby!)
    When I get into the car
    And turn the key
    Then the engine roars to life

Wiem, że ten scenariusz brzmi trochę głupio, ale jest to wymóg bardzo wysoki, ukierunkowany na produkt i użytkownika końcowego. Samo otwarcie drzwi, przekręcenie kluczyka i uruchomienie silnika wymaga wielu różnych elementów współpracujących ze sobą. Ten jeden test nie wystarczy, aby upewnić się, że pojazd działa poprawnie. Musisz przetestować rozrusznik, akumulator, alternator, kluczyk, stacyjkę --- i lista jest długa --- tylko po to, żeby dostać się do samochodu i uruchomić. Każdy z tych elementów wymaga własnych testów.

Powyższy scenariusz to test „dużego obrazu”. Każdy element pojazdu wymaga testów „małego obrazu”, aby upewnić się, że działają prawidłowo w całości.

Oprogramowanie do budowania i testowania jest takie samo pod wieloma względami. Projektujesz od góry do dołu, a następnie budujesz od dołu do góry. Dlaczego drzwi mają się unieść, jeśli nie można nawet uruchomić silnika? Po co mieć rozrusznik, jeśli nie ma baterii?

Twój zespół ds. Produktów opracuje testy akceptacyjne i przeprowadzi je w ogórku. To daje „duży obraz”. Teraz zespół inżynierów musi zaprojektować odpowiednie komponenty i sposób ich interakcji, a następnie przetestować każdy z nich osobno - to są testy jednostkowe.

Po przejściu testów jednostkowych rozpocznij wdrażanie scenariuszy Ogórek. Po ich przekazaniu dostarczyłeś to, o co poprosił zespół produktu.

Próbuję zrozumieć BDD. Przeczytałem kilka artykułów i jak zrozumiałem, BDD to „następny krok” od TDD. Mówię to, ponieważ uważam, że oba są bardzo podobne, i jak mogłem przeczytać w tym artykule, BDD narodziło się jako ulepszenie z TDD.

W rzeczywistości nie, BDD nie jest „kolejnym krokiem” od TDD. To jest TDD. A dokładniej, jest to zmiana sformułowania TDD.

Twórcy BDD zauważyli, że główną przeszkodą w zrozumieniu, że TDD nie dotyczy testowania, ale specyfikacji behawioralnej było to, że cała terminologia TDD dotyczy testowania, a nie specyfikacji behawioralnej. To tak, jakby próbować nie myśleć o różowym słoniu, gdy ktoś mówi do ciebie „staraj się nie myśleć o różowym słoniu”, z wyjątkiem dodatkowej komplikacji przebywania w pokoju pełnym różowych słoni i faceta ciągle krzyczącego „różowy słoń, różowy słoń, różowy słoń ”do ucha.

Tak więc sformułowali TDD pod względem specyfikacji behawioralnej. „Testy” i „przypadki testowe” są teraz „przykładami”, „jednostki” to „zachowania”, „twierdzenia” to „oczekiwania” i tak dalej.

Metodologia jest jednak nadal taka sama. Zaczynasz od testu akceptacyjnego (mam na myśli „funkcję”), przybliżasz do testu jednostkowego (mam na myśli „przykład”), pomniejszasz itd.

Chciałbym przeprowadzić testy jednostkowe. Jak przetestować kod sprawdzający, czy w dozowniku są pieniądze? Lub że gotówka jest wydawana? Czy konto jest obciążane w razie potrzeby? Jak łączyć testy jednostkowe z testami „BA Created”?

Tak samo jak w TDD. Możesz pisać swoje funkcje i przykłady w różnych ramach (np. Cucumber i RSpec) lub nawet w różnych językach (np. Pisanie przykładów projektu C w C i funkcji w FIT / Fitnesse), możesz użyć jednej struktury funkcji dla obu ( np. pisanie przykładów i funkcji w Cucumber) lub możesz użyć struktury pojedynczych przykładów dla obu (np. pisanie obu w RSpec). W ogóle nie musisz używać frameworka.

Przykładem poprawnej TDD (która jest identyczna z BDD) przy użyciu tylko jednego frameworka jest sam JUnit, który zawiera mieszankę testów jednostkowych (przykłady) i testów funkcjonalnych / integracyjnych (cechy), wszystkie napisane w samym JUnit.

Wierzę, że Kent Beck nazywa to „powiększaniem”. Rozpocznij na wysokim poziomie, następnie „powiększ” szczegóły, a następnie ponownie się wycofaj.

Oświadczenie: Nie jestem ekspertem od BDD, ale staram się przedstawić mój punkt widzenia na artykuł, do którego linkujesz.

TDD to technika implementacji - najpierw piszesz test, następnie implementujesz metodę, uruchamiasz test, refaktoryzujesz i dodajesz kolejne testy dla tej samej metody lub nowej metody. TDD tak naprawdę nie definiuje żadnych zasad wyboru nazw klas lub metod, to zależy od ciebie. TDD również nie mówi „kiedy skończysz”.

Dlatego za każdym razem, gdy piszesz test dla nowej metody, musisz wybrać nazwę metody - i właśnie w tym miejscu pojawia się BDD. Wybierając nazwy metod przy użyciu terminów biznesowych z powyższego scenariusza i wybierając je w sposób opisujący zachowanie twojej klasy, robisz BDD. Ilekroć zadajesz sobie pytanie „czy muszę dodawać kolejne testy”, możesz przejrzeć scenariusze podane przez licencjata i sprawdzić, czy całkowicie zaimplementowałeś wszystkie potrzebne części. Jeśli nie, musisz dodać więcej testów.

Autor artykułu sugeruje również stosowanie schematu nazewnictwa bardziej związanego z zachowaniem przy wyborze nazw testów, dlatego sugeruje zastąpienie JUnit narzędziem, które nie opiera się na schemacie nazewnictwa, w którym każdy przypadek testowy musi zaczynać się od nazwa „test”. Chociaż nie znam JBehave, myślę, że to główna różnica między tym narzędziem a Junit.

Co więcej, scenariusze BDD będą również planem testów integracyjnych - które zazwyczaj dodajesz po opracowaniu nazw metod przez TDD i po dodaniu rozsądnej liczby testów jednostkowych.

Tak więc, o ile mi wiadomo, TDD jest narzędziem, którego można używać jako części BDD, a BDD pomaga pisać odpowiednie testy i nadawać im lepsze nazwy.