2. Behaviour driven development
Behaviour driven development (BDD)
• opiera się na Test Driven Development (TDD)
• metodyka “outside-in”
• Każda funkcjonalność jest ujęta, jako historia
(story), która definiuje zakres funkcjonalności
razem z kryterium akceptacyjnym.
3. BDD stwarza wspólne słownictwo dla analityka,
testera, developera oraz biznesu, aby
wyeliminować niejednoznaczności i
niezrozumienie pojawiające się w rozmowach
między nimi.
4. Podział BDD
SpecBDD
• narzędzie do rozwoju specyfikacji dla niskiego
poziomu implementacji części i komunikacji pomiędzy
nimi.
• ewolucja zwykłych testów jednostkowych.
StoryBDD
• tworzenie czytelnych dla człowieka, skierowanych dla
biznesu opisów zachowań.
• ewolucja DDD i testów funkcjonalnych.
• z StoryBDD pisze się scenariusze dla interesariuszy
5. Feature
Funkcjonalność jest opisana przez plik <my-
feature.feature> - zawiera dokładnie jedną
funkcjonalność.
Feature jest zbiorem przypadków zwanych
“scenariuszami” (scenario). Każdy scenariusz
zdefiniowany jest przez:
Context (Given)
Zdarzenia (When)
Oczekiwany rezultat (Then)
6. Bankomat
As a X
I want Y
so that Z
Feature: Customer withdraws cash
As a customer,
I want to withdraw cash from an ATM,
so that I dont have to wait in line at the bank.
7. Jest kilka scenariuszy do rozważenia:
• konto może mieć środki
• konto może być na debecie, ale w limicie debetu
• konto może mieć przekroczony limit debetu
• jak konto ma środki, ale wypłata sprawia, że
będzie przekroczony limit debetu
• bankomat nie ma wystarczająco gotówki
8. Scenario: Account is in credit
Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned
9. • Jeżeli coś nie jest opisane w pliku .feature to nie
znaczy, że ta część aplikacji jest nadmiarowa
albo powinna być usunięta – to po prostu znaczy,
że ta część nie jest ważna dla biznesu, chociaż
część kodu nie jest ważna dla niego to ciągle
może być ona ważną częścią aplikacji.
• Pliki *.feature to nie są testy. Są to opisy
funkcjonalności projektu. Behat daje możliwość
(dzięki definicjom kroków) automatycznego
sprawdzania, kiedy te funkcjonalności są
zaimplementowane.
10. Behat w praktyce
Należy dodać do composer.json następujące linijki:
{
...
"require": {
...
"behat/symfony2-extension": "*",
"behat/mink-extension": "*",
"behat/mink-browserkit-driver"
},
"config": {
"bin-dir": "bin/"
},
...
}
11. W katalogu głównym trzeba stworzyć plik
behat.yml
default:
extensions:
BehatSymfony2ExtensionExtension:
mink_driver: true
BehatMinkExtensionExtension:
default_session: 'symfony2'
12. Rozpoczęcie pracy
php bin/behat init @AcmeDemoBundle
(php vendorbehatbehatbinbehat
init @AcmeDemoBundle)
Po wykonaniu komendy Behat tworzy folder
Features a w nim folder Context z plikiem
FeatureContext.php w srcAcmeDemoBundle.
13. Pierwszy plik .feature
• Załóżmy, że w naszej aplikacji trzeba
zaimplementować funkcję logowania, aby
umożliwić dostęp zalogowanym użytkownikom do
szerszej części serwisu.
• Należy utworzyć pierwszy plik .feature. Dobrą
praktyką jest grupowanie plików .feature
dotyczących tej samej funkcjonalności w
specjalnym folderze tej funkcjonalności. W
folderze srcAcmeDemoBundleFeatures
utworzony został folder security a w nim plik
login.feature:
14. Feature: Login
In order to have access to the wide functionality
of application
As a guest
I need to login
Scenario: Going to login page will show login form
Given there is user "user" with password
"userpass" and role "ROLE_USER"
And I am on „demo/secured/login"
Then I should see "Username" in the
"label[for=username]" element
And I should see "Password" in the
"label[for=password]" element
And I should see an "input[type=submit]"
element
15. Scenario: Passing right values will
login
Given there is user "user" with
password "userpass" and role
"ROLE_USER"
And I am on „demo/secured/login"
When I fill in "Username" with
"user"
And I fill in "Password" with
"userpass"
And I press "Login"
Then I should be on "/"
16. Testujemy czy napisany kod spełnia napisane
przez nas feature:
php vendorbehatbehatbinbehat
@AcmeDemoBundlesecurity
Behat zwraca wynik:
2 scenarios (2 undefined)
11 steps (11 undefined)
0m0.165s
18. /**
* @Given /^there is user "([^"]*)" with password
"([^"]*)" and role "([^"]* )"$/
*/
public function thereIsUserWithPasswordAndRole($arg1,
$arg2, $arg3)
{
throw new PendingException();
}
/**
* @Given /^I am on "([^"]*)"$/
*/
public function iAmOn($arg1)
{
throw new PendingException();
}
19. Mink
Mink symuluje interakcje przeglądarki z aplikacją.
Aby pracować z narzędziem Mink należy zmienić
kod w pliku FeatureContext.php na:
class FeatureContext extends
MinkContext implements
KernelAwareInterface
21. <?php
namespace AcmeDemoBundleFeaturesContext;
use BehatMinkExtensionContextMinkContext,
BehatBehatExceptionPendingException;
class GuestContext extends MinkContext
{
/**
* @Given /^there is user "([^"]*)" with password
"([^"]*)" and role "([^"]*)"$/
*/
public function thereIsUserWithPasswordAndRole($arg1,
$arg2, $arg3)
{
throw new PendingException();
}
}
22. Schemat pracy w metodyce BDD jest
następujący: należy napisać się test, a następnie
przetestować system oraz w razie potrzeby
poprawiać go tak długo aż przejdzie testy.
Należy zaimplementować test oraz napisać kodu
programu. Po przetestowaniu programu Behat
zwraca wynik:
2 scenarios (2 passed)
11 steps (11 passed)
0m1.682s
Sukces!
23. Feature: Login
In order to have access to the wide functionality of
application
As a guest
I need to login
Background:
Given there is user "user" with password "userpass" and role
"ROLE_USER"
And I am on "demo/secured/login"
Scenario: Going to login page will show login form
Then I should see "Username" in the "label[for=username]"
element
And I should see "Password" in the "label[for=password]"
element
And I should see an "input[type=submit]" element
…
24. Scenario outline: Going to welcome page
will show personalized welcome message
Given I am logged in as <user> with
password <password>
And I am on "/"
Then I should see <message>
Examples:
| user | password | message |
| user | userpass | Hello user! |
| user1 | userpass1 | Hello user1! |
25. Feature: Welcome text
In order to have personalized front page of application
As a user
I need to go to welcome page
Background:
Given there is user "user" with password "userpass" and role
"ROLE_USER"
And there is user "user1" with password "userpass" and role
"ROLE_USER"
And I am on "/"
Scenario: Going to welcome page will show personalized welcome
message
Given I am logged in as "user" with password "userpass"
And I am on "/"
Then I should see "Hello user!"
Scenario: Going to welcome page will show personalized welcome
message
Given I am logged in as "user1" with password "userpass"
And I am on "/"
Then I should see "Hello user1!"
26. Co dalej?
We wrześniu 2012 na konferencji SymfonyLive w
Londynie Konstantin Kudryashov (twórca Behat)
oraz Marcello Duarte (phpspec2) pokazali, w jaki
sposób pracować z kodem, aby korzystać z
„Fullstack BDD”. Slajdy z tego wystąpienia
znajdują się na stronie: http://slidesha.re/RRKQFb,
a uzupełnia je wpis na blogu:
http://everzet.com/post/31581124270/fullstack-
bdd-2012-wrapup.
Editor's Notes
BehaviourDriven DevelopmentFeaturesPraca z Behat
Behaviour driven development (BDD) opierasięna Test Driven Development (TDD) jest metodyką “outside-in”. Rozpoczyna na zewnątrz przez identyfikowanie wymagań biznesu i następuje przekształcenie w funkcjonalności, które te wymagania spełniają. Każda funkcjonalność jest ujęta, jako historia (story), która definiuje zakres funkcjonalności razem z kryterium akceptacyjnym. BDD stwarza wspólne słownictwo dla analityka, testera, developera oraz biznesu, aby wyeliminować niejednoznaczności i niezrozumienie pojawiające się w rozmowach między nimi.
Są dwa dopełniające się, ale różne sposoby wykorzystywania BDD – SpecBDD oraz StoryBDD:SpecBDD jest narzędziem do rozwoju specyfikacji dla niskiego poziomu implementacji części i komunikacji pomiędzy nimi. To ewolucja zwykłych testów jednostkowych. StoryBDD skupia się na tworzeniu czytelnych dla człowieka, skierowanych dla biznesu opisów zachowań. Jest ewolucją DomainDriven Development i testów funkcjonalnych. Z StoryBDD pisze się scenariusze dla interesariuszy, ale te scenariusze nie są testami i nie mają za cel opisanie całej funkcjonalności aplikacji, poza tymi interesującymi dla interesariuszy. Chociaż scenariusze nie są testami ich faza akceptacji może zostać zautomatyzowana.Behat automatyzuje testy akceptacyjne zwinnej metodologii Scrum. Każdy test napisany jest w naturalnym języku składnią Gherkin. Behat jest narzędziem StoryBDD.
Funkcjonalność w narzędziu Behat jest opisana przez plik <my-feature.feature>, który może zawierać dokładnie jedną funkcjonalność.Feature jest zbiorem przypadków zwanych “scenariuszami” (scenario). Każdy scenariusz zdefiniowany jest przez:Context (Given)Zdarzenia (When)Oczekiwany rezultat (Then)
Szablon początku pliku .feature spełnia następujący schemat:As a XI want Yso that Z Gdzie Y jest funkcjonalnością, Z korzyścią lub wartością funkcjonalności, a X jest osobą (albo rolą), która czerpie korzyść. Siłą tego rozwiązania jest kładziony nacisk na zidentyfikowanie wartości scenariusza, kiedy pierwszy raz jest definiowana. Aby to zilustrować użycie plików .feature można użyć przykładu z bankomatem (używam przykładu z artykułu Introducing BDD). Jeden z plików .feature mógłbywyglądaćtak:Feature: Customer withdraws cash As a customer, I want to withdraw cash from an ATM, so that I dont have to wait in line at the bank.
Skąd wiadomo, że funkcjonalność wypłaty gotówki z bankomatu jest zaimplementowana? Jest kilka scenariuszy do rozważenia: konto może mieć środki, konto może być na debecie, ale w limitu debetu, konto może mieć przekroczony limit debetu. Oczywiście będą też inne scenariusze takie jak konto ma środki, ale wypłata sprawia, że będzie przekroczony limit debetu, albo bankomat nie ma wystarczająco gotówki.
Używając szablonu given-when-then pierwszy scenariusz może wyglądać tak:Należy zauważyć, że słowo “and” zostało użyte, aby połączyć wielokrotne wystąpienia given lub thenOba scenariusze są oparte na tym samym zdarzeniu i mają nawet te same „given” i „then”. Można czerpać z tego korzyść poprzez wielokrotne ich wykorzystanie. W dalszej części zostanie przedstawione jak dzieje się to za pomocą Behata.
Przedstawione zostanie testowanie aplikacji webowej korzystającej z frameworka Symfony2.Następnie: phpcomposer.pharupdate
Pracę rozpoczyna się wywołując komendę(Pracując w Windows 7 zamiast powyższej komendy należy wykonać następującą:
Słowa: „Given”, „When”, „Then” oraz „And” nie mają specjalnego znaczenia w kodzie, służą do oznaczania kroków oraz podwyższają ich czytelność.
Wszystkie kroki kończą się wynikiem „undefined”, ponieważ nie dopasowały się do żadnej definicji w pliku FeatureContext.
Success – definicja została znaleziona oraz wykonywanie nie wyrzuciło wyjątkuUndefinied – definicja nie została znaleziona, wszystkie następujące kroki zostaną pominiętePending – definicja rzuciła PendingException, co znaczy, że trzeba wykonać dodatkową pracęFailure – definicja wyrzuca wyjątek; Behat pominie pozostałe krokiSkipped – krok nie został wykonanyAmbigous – wiele definicji pasuje do krokuRedundant – wiele definicji ma ten sam wzorzec
Behat ułatwia zadanie pisania definicji kroków i generuje kod, który można wkleić do FeatureContext.php. Nie jest to konieczne, ponieważ testowanie aplikacji webowych jest łatwiejsze dzięki narzędziu Mink.
Po wywołaniu jeszcze raz Behata zauważamy, że nasz pierwszy krok kończy się wyjątkiem, a następne zostają pominięte. Dzieje się tak, ponieważ zakończenie błędem kroku może sprawić, że następne mogą źle się wywoływać
Należy zauważyć, że metoda thereIsUserWithPasswordAndRole() ciągle wymaga zaimplementowania. Dobrą praktyką jest dzielenie kontekstu, dlatego trzeba utworzyć nowy kontekst dla gościa. W tym celu należy dodać do konstruktora FeatureContext jedną linijkę
Tworzę plik GuestContext.php i wklejam do niego schemat metody zaproponowanej przez Behata.
Jednak jest jeszcze coś do poprawienia. Po przyjrzeniu się definicjom scenariuszy można zauważyć, że część kroków się powtarza. Aby nie powtarzać niepotrzebnie definicji kroków używa się Backgrounds.
Kolejną funkcjonalnością do zaimplementowania w serwisie jest spersonalizowana strona główna aplikacji. Jedną z jej funkcji jest odpowiednie przywitanie zalogowanych użytkowników. Należy utworzyć folder frontPage a w nim welcome.feature:
Można zauważyć, że oba scenariusze sprawdzają dokładnie to samo jedyne, czym się różnią to dane. Możliwa jest zamianadwóchpowyższychscenariuszyna:
