BDD - TDD w stylu BDD
W TDD termin „testy akceptacyjne” wprowadza w błąd. Testy akceptacyjne faktycznie reprezentują oczekiwane zachowanie systemu. W praktykach Agile kładzie się nacisk na współpracę całego zespołu oraz interakcje z klientem i innymi interesariuszami. To spowodowało konieczność stosowania terminów, które są łatwo zrozumiałe dla wszystkich zaangażowanych w projekt.
TDD sprawia, że myślisz o wymaganym Behavior dlatego termin „zachowanie” jest bardziej przydatny niż termin ‘Test’. BDD to programowanie sterowane testami ze słownictwem, które koncentruje się na zachowaniu, a nie na testach.
Mówiąc słowami Dana Northa: „Przekonałem się, że przejście od myślenia w testach do myślenia w zachowaniu jest tak głębokie, że zacząłem nazywać TDD jako BDD lub Behavior Driven Development.” TDD skupia się na tym, jak coś będzie działać, BDD skupia się na tym, dlaczego w ogóle to budujemy.
BDD odpowiada na następujące pytania, z którymi często spotykają się twórcy:
| Pytanie | Odpowiedź |
|---|---|
| Gdzie zacząć? | od zewnątrz do wewnątrz |
| Co przetestować? | Historie użytkownika |
| Czego nie testować? | coś jeszcze |
Odpowiedzi te dają następującą strukturę opowieści -
Story Framework
Jak [Role]
chcę [Feature]
po to aby [Benefit]
To znaczy: „Kiedy Feature jest wykonywany, wynikowy Benefit jest dla osoby grającej Role.'
BDD dodatkowo odpowiada na następujące pytania -
| Pytanie | Odpowiedź |
|---|---|
| Ile przetestować za jednym razem? | bardzo mało skoncentrowany |
| Jak nazwać ich testy? | szablon zdania |
| Jak zrozumieć, dlaczego test się nie udał | dokumentacja |
Odpowiedzi te dają przykładowe ramy w następujący sposób -
Example Framework
Given jakiś kontekst początkowy,
When zdarzenie ma miejsce,
Then zapewnić pewne wyniki.
Oznacza to: „Zaczynając od kontekstu początkowego, kiedy ma miejsce określone wydarzenie, wiemy, jakie są jego skutki should be”.
Tak więc przykład pokazuje oczekiwane zachowanie systemu. Przykłady służą do zilustrowania różnych scenariuszy działania systemu.
Historia i scenariusze
Rozważmy następującą ilustrację autorstwa Dana Northa dotyczącą systemu bankomatów.
Fabuła
As a klient,
I want do wypłaty gotówki z bankomatu,
so that Nie muszę czekać w kolejce do banku.
Scenariusze
Istnieją dwa możliwe scenariusze tej historii.
Scenario 1 - Konto jest kredytowane
Given konto jest kredytowane
And karta jest ważna
And dystrybutor zawiera gotówkę
When klient żąda gotówki
Then upewnić się, że konto zostało obciążone
And upewnić się, że wydano gotówkę
And upewnij się, że karta została zwrócona
Scenario 2 - Konto przekroczyło limit debetu
Given konto jest przekroczone
And karta jest ważna
When klient żąda gotówki
Then upewnij się, że wyświetlany jest komunikat o odrzuceniu
And upewnij się, że gotówka nie zostanie wydana
And upewnij się, że karta została zwrócona
Wydarzenie jest takie samo w obu scenariuszach, ale kontekst jest inny. Dlatego wyniki są różne.
Cykl rozwoju
Cykl rozwoju BDD to outside-in podejście.
Step 1- Napisz przykład wartości biznesowej wysokiego poziomu (na zewnątrz) (używając Cucumber lub RSpec / Capybara), który będzie czerwony. (RSpec tworzy framework BDD w języku Ruby)
Step 2 - Napisz niższy (wewnętrzny) przykład RSpec dla pierwszego kroku implementacji, który zostanie oznaczony na czerwono.
Step 3 - Zaimplementuj minimalny kod, aby przekazać ten przykład niższego poziomu, zobacz, czy będzie zielony.
Step 4 - Napisz następny przykład RSpec niższego poziomu, przechodząc do kroku 1, który staje się czerwony.
Step 5 - Powtarzaj kroki 3 i 4, aż przykład wysokiego poziomu w kroku 1 stanie się zielony.
Note - Należy pamiętać o następujących kwestiach -
Red/green stan to status pozwolenia.
Gdy testy niskiego poziomu są zielone, masz uprawnienia do pisania nowych przykładów lub refaktoryzacji istniejącej implementacji. Nie możesz, w kontekście refaktoryzacji, dodawać nowej funkcjonalności / elastyczności.
Kiedy twoje testy niskiego poziomu są czerwone, masz uprawnienia do pisania lub zmiany kodu implementacji tylko po to, aby istniejące testy stały się zielone. Musisz oprzeć się pokusie napisania kodu, aby przejść następny test, który nie istnieje, lub zaimplementować funkcje, które uważasz za dobre (klient by o to nie poprosił).