Darmowy fragment publikacji:
Tytuł oryginału: BDD in Action: Behavior-Driven Development for the whole software lifecycle
Tłumaczenie: Radosław Meryk
Projekt okładki: Studio Gravite / Olsztyn
Obarek, Pokoński, Pazdrijowski, Zaprucki
ISBN: 978-83-283-1747-5
Original edition copyright © 2015 by Manning Publications Co.
All rights reserved.
Polish edition copyright © 2016 by HELION SA.
All rights reserved.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means,
electronic or mechanical, including photocopying, recording or by any information storage retrieval system,
without permission from the Publisher.
Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej
publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną,
fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje
naruszenie praw autorskich niniejszej publikacji.
Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich
właścicieli.
Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były
kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane
z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie
ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji
zawartych w książce.
Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.
Wydawnictwo HELION
ul. Kościuszki 1c, 44-100 GLIWICE
tel. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
WWW: http://helion.pl (księgarnia internetowa, katalog książek)
Pliki z przykładami omawianymi w książce można znaleźć pod adresem:
ftp://ftp.helion.pl/przyklady/bdddzi.zip
Drogi Czytelniku!
Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres
http://helion.pl/user/opinie/bdddzi
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.
Printed in Poland.
• Kup książkę
• Poleć książkę
• Oceń książkę
• Księgarnia internetowa
• Lubię to! » Nasza społeczność
Spis tre(cid:258)ci
S(cid:239)owo wst(cid:218)pne 11
Przedmowa 15
Podzi(cid:218)kowania 17
O tej ksi(cid:200)(cid:285)ce 19
CZ(cid:125)(cid:165)(cid:109) I. PIERWSZE KROKI ......................................................................... 23
Rozdzia(cid:239) 1. Budowanie oprogramowania, które sprawia ró(cid:285)nic(cid:218) 25
1.1. BDD z wysoko(cid:258)ci 15 kilometrów 27
1.2.
Jakie problemy próbujemy rozwi(cid:200)zywa(cid:202)? 29
1.2.1. W(cid:239)a(cid:258)ciwe budowanie oprogramowania 30
1.2.2.
1.2.3.
Budowanie w(cid:239)a(cid:258)ciwego oprogramowania 32
Ograniczenia wiedzy — radzenie sobie z informacj(cid:200) niepewn(cid:200) 32
1.3. Wprowadzenie do programowania sterowanego zachowaniami 34
1.3.1.
1.3.2.
1.3.3.
BDD pierwotnie zaprojektowano jako ulepszon(cid:200) wersj(cid:218) TDD 35
Techniki BDD równie(cid:285) sprawdzaj(cid:200) si(cid:218) jako narz(cid:218)dzia analizy wymaga(cid:241) 37
Zasady i praktyki BDD 38
1.4. Korzy(cid:258)ci z BDD 52
1.4.1. Mniejsze marnotrawstwo 52
1.4.2.
1.4.3.
1.4.4.
Ni(cid:285)sze koszty 52
(cid:146)atwiejsze i bezpieczniejsze zmiany 53
Szybsze publikacje 53
1.5. Wady i potencjalne problemy zwi(cid:200)zane ze stosowaniem praktyk BDD 53
1.5.1.
1.5.2.
Stosowanie praktyk BDD wymaga du(cid:285)ego zaanga(cid:285)owania
i wspó(cid:239)pracy 53
Praktyki BDD sprawdzaj(cid:200) si(cid:218) najlepiej w kontek(cid:258)cie metodologii Agile
lub innej metodologii iteracyjnej 53
Praktyki BDD nie sprawdzaj(cid:200) si(cid:218) dobrze w projektach typu silos 54
(cid:189)le napisane testy mog(cid:200) prowadzi(cid:202) do wy(cid:285)szych kosztów utrzymania 54
1.5.3.
1.5.4.
Podsumowanie 54
1.6.
Rozdzia(cid:239) 2. BDD z lotu ptaka 57
2.1. Wprowadzenie w tematyk(cid:218) aplikacji rozk(cid:239)adu jazdy poci(cid:200)gów 58
2.2. Okre(cid:258)lenie korzy(cid:258)ci ze stosowania proponowanej aplikacji 60
2.3. Analiza wymaga(cid:241) — odkrywanie i zrozumienie funkcji 60
2.3.1.
2.3.2.
2.3.3.
Opisywanie funkcji 60
Podzia(cid:239) cech funkcjonalnych na historyjki 62
Ilustrowanie historyjek przyk(cid:239)adami 63
Poleć książkęKup książkę4
2.4.
Spis tre(cid:258)ci
Implementacja — budowanie i dostarczanie cech funkcjonalnych 64
2.4.1.
2.4.2.
2.4.3.
2.4.4.
2.4.5.
Od przyk(cid:239)adów do kryteriów akceptacji 64
Konfigurowanie narz(cid:218)dzi Maven i Git 65
Specyfikacje wykonywalne — automatyzacja kryteriów akceptacji 67
Automatyczne testy — implementacja kryteriów akceptacji 72
Testy jako dynamiczna dokumentacja 81
2.5. Utrzymanie 81
2.6.
Podsumowanie 85
CZ(cid:125)(cid:165)(cid:109) II. CZEGO CHC(cid:125)? DEFINIOWANIE WYMAGA(cid:148)
Z WYKORZYSTANIEM BDD .........................................................87
Rozdzia(cid:239) 3. Zrozumie(cid:202) cele biznesowe. Wstrzykiwanie
cech funkcjonalnych i zwi(cid:200)zane z tym techniki 89
Poznajemy firm(cid:218) Flying High 91
3.1.
3.2. Wstrzykiwanie funkcji 92
3.2.1. Wyszukiwanie warto(cid:258)ci 93
3.2.2. Wstrzykiwanie cech funkcjonalnych 93
3.2.3. Wskazanie przyk(cid:239)adów 94
3.2.4.
Podsumowanie 94
3.3. Co chcesz osi(cid:200)gn(cid:200)(cid:202)? Zacznij od wizji 96
3.3.1.
3.3.2.
Formu(cid:239)a wizji 97
Korzystanie z szablonów formu(cid:239)y wizji 98
3.4. W jaki sposób firma skorzysta na projekcie? Identyfikowanie celów biznesowych 99
3.4.1.
3.4.2.
3.4.3.
Pisanie dobrych celów biznesowych 100
Poka(cid:285) mi pieni(cid:200)dze — cele biznesowe a przychody 101
(cid:165)ci(cid:200)ganie ze „stosu dlaczego” — u(cid:258)ci(cid:258)lanie celów biznesowych 103
3.5. Mapowanie wp(cid:239)ywu — podej(cid:258)cie wizualne 106
3.6. Kto na tym skorzysta? Identyfikowanie interesariuszy i ich potrzeb 110
3.7. Co trzeba zbudowa(cid:202)? Identyfikowanie zdolno(cid:258)ci 112
3.8.
Jakie cechy funkcjonalne zapewni(cid:200) najwi(cid:218)kszy wska(cid:283)nik ROI?
Model dopasowania do celów 114
Cechy wyró(cid:285)niaj(cid:200)ce 116
3.8.1.
3.8.2.
Cechy równowa(cid:285)ne 116
Cechy partnerskie 117
3.8.3.
3.8.4.
Cechy o minimalnym wp(cid:239)ywie 117
Podsumowanie 117
3.9.
Rozdzia(cid:239) 4. Definiowanie i ilustrowanie cech funkcjonalnych 119
4.1. Co to jest cecha funkcjonalna? 120
4.1.1.
4.1.2.
4.1.3.
4.1.4.
Cechy funkcjonalne dostarczaj(cid:200) zdolno(cid:258)ci 122
Cechy funkcjonalne mo(cid:285)na podzieli(cid:202) na (cid:239)atwiejsze do zarz(cid:200)dzania
fragmenty 126
Cecha funkcjonalna mo(cid:285)e by(cid:202) opisana za pomoc(cid:200) jednej lub kilku
historyjek u(cid:285)ytkowników 128
Cecha funkcjonalna nie jest historyjk(cid:200) u(cid:285)ytkownika 131
Poleć książkęKup książkęSpis tre(cid:258)ci
5
Eposy to naprawd(cid:218) du(cid:285)e historyjki u(cid:285)ytkownika 132
Nie wszystko pasuje do hierarchii 133
4.1.5.
4.1.6.
Ilustrowanie cech funkcjonalnych przyk(cid:239)adami 134
4.2.
4.3. Realne opcje — podejmuj zobowi(cid:200)zania dopiero wtedy, kiedy musisz 140
4.3.1.
4.3.2.
4.3.3.
Opcje maj(cid:200) warto(cid:258)(cid:202) 141
Opcje wygasaj(cid:200) 143
Nigdy nie zobowi(cid:200)zuj si(cid:218) zbyt wcze(cid:258)nie, je(cid:258)li nie wiesz dlaczego 143
4.4. Celowe odkrywanie 144
4.5. Od przyk(cid:239)adów do dzia(cid:239)aj(cid:200)cego oprogramowania — szerszy obraz 145
4.6.
Podsumowanie 146
Rozdzia(cid:239) 5. Od przyk(cid:239)adów do wykonywalnych specyfikacji 149
5.1.
5.2.
Przekszta(cid:239)canie konkretnych przyk(cid:239)adów na wykonywalne scenariusze 151
Pisanie wykonywalnych scenariuszy 154
5.2.1.
5.2.2.
5.2.3.
5.2.4.
5.2.5.
Plik cech funkcjonalnych zawiera tytu(cid:239) i opis 154
Opisywanie scenariuszy 156
Struktura „Zak(cid:239)adaj(cid:200)c... Gdy... Wtedy” 157
Uzupe(cid:239)niaj(cid:200)ce s(cid:239)owa kluczowe 158
Komentarze 159
5.3. Wykorzystanie tabel w scenariuszach 160
5.4.
U(cid:285)ywanie tabel w pojedynczych krokach 160
5.3.1.
5.3.2. Wykorzystanie tabel przyk(cid:239)adów 161
Scenariusze ekspresywne — wzorce i antywzorce 165
5.4.1.
5.4.2.
5.4.3.
5.4.4.
5.4.5.
Pisanie ekspresywnych kroków Zak(cid:239)adaj(cid:200)c 165
Pisanie ekspresywnych kroków Gdy 166
Pisanie ekspresywnych kroków Wtedy 167
Podawanie t(cid:239)a i kontekstu 168
Unikanie zale(cid:285)no(cid:258)ci mi(cid:218)dzy scenariuszami 170
5.5. Organizowanie scenariuszy przy u(cid:285)yciu plików cech funkcjonalnych i tagów 171
5.5.1.
5.5.2.
Scenariusze zapisuje si(cid:218) w plikach opisu cech funkcjonalnych 172
Plik opisu cechy funkcjonalnej mo(cid:285)e zawiera(cid:202) jeden lub wi(cid:218)cej
scenariuszy 172
Organizowanie plików opisu cech funkcjonalnych 173
Opisywanie scenariuszy za pomoc(cid:200) tagów 174
5.5.3.
5.5.4.
Podsumowanie 176
5.6.
Rozdzia(cid:239) 6. Automatyzacja scenariuszy 179
6.1. Wprowadzenie do automatyzowania scenariuszy 182
6.2.
Definicje kroków interpretuj(cid:200) tekst scenariuszy 182
6.1.1.
6.1.2.
Zachowaj prostot(cid:218) metod definicji kroków 184
Implementacja definicji kroków — zasady ogólne 186
6.2.1.
6.2.2.
6.2.3.
6.2.4.
6.2.5. Wykorzystywanie danych tabelarycznych z definicji kroków 190
6.2.6.
6.2.7. Wyniki scenariusza 192
Instalowanie narz(cid:218)dzi BDD 186
Implementacja definicji kroków 187
Przekazywanie parametrów do implementacji kroków 187
Utrzymywanie stanu pomi(cid:218)dzy krokami 188
Implementacja scenariuszy bazuj(cid:200)cych na przyk(cid:239)adach 191
Poleć książkęKup książkę6
Spis tre(cid:258)ci
6.3. Bardziej efektywna implementacja BDD z wykorzystaniem narz(cid:218)dzia
Thucydides 193
6.4. Automatyzowanie scenariuszy w Javie z wykorzystaniem JBehave 194
Instalowanie i konfigurowanie narz(cid:218)dzia JBehave 194
Definicje kroków JBehave 195
6.4.1.
6.4.2.
6.4.3. Wspó(cid:239)dzielenie danych pomi(cid:218)dzy krokami 197
6.4.4.
6.4.5.
6.4.6. Warianty wzorców 200
6.4.7.
Przekazywanie tabel do kroków 198
Definicje kroków dla tabel przyk(cid:239)adów 199
Niepowodzenia i b(cid:239)(cid:218)dy w wynikach scenariuszy 200
6.5. Automatyzowanie scenariuszy w Javie przy u(cid:285)yciu narz(cid:218)dzia
Konfiguracja i struktura projektu Cucumber-JVM 202
Definicje kroków Cucumber-JVM 203
Cucumber-JVM 202
6.5.1.
6.5.2.
6.5.3. Warianty wzorców 204
6.5.4.
6.5.5.
6.5.6. Wspó(cid:239)dzielenie danych pomi(cid:218)dzy krokami 206
6.5.7.
Przekazywanie tabel do definicji kroków 205
Definicje kroków dla tabel przyk(cid:239)adów 206
Kroki oczekuj(cid:200)ce i wyniki kroków 207
6.6. Automatyzowanie scenariuszy w Pythonie z wykorzystaniem Behave 207
6.6.1.
6.6.2.
6.6.3.
6.6.4.
6.6.5.
6.6.6.
6.6.7.
Instalacja systemu Behave 208
Struktura projektu Behave 208
Definicje kroków Behave 209
(cid:146)(cid:200)czenie kroków 209
Definicje kroków z wykorzystaniem osadzonych tabel 210
Definicje kroków dla tabel przyk(cid:239)adów 210
Uruchamianie scenariuszy w Behave 210
6.7. Automatyzowanie scenariuszy w .NET z wykorzystaniem SpecFlow 211
Konfigurowanie SpecFlow 211
Dodawanie plików opisu cech funkcjonalnych 211
Uruchamianie scenariuszy 213
Definicje kroków w SpecFlow 213
6.7.1.
6.7.2.
6.7.3.
6.7.4.
6.7.5. Wspó(cid:239)dzielenie danych pomi(cid:218)dzy krokami 214
6.7.6.
Definicje kroków z wykorzystaniem tabel przyk(cid:239)adów 215
6.8. Automatyzowanie scenariuszy w JavaScript z wykorzystaniem systemu
Cucumber-JS 216
6.8.1.
6.8.2.
6.8.3.
6.8.4.
Podsumowanie 220
Konfigurowanie systemu Cucumber-JS 216
Pisanie plików opisu funkcji w Cucumber-JS 217
Implementowanie kroków 218
Uruchamianie scenariuszy 219
6.9.
CZ(cid:125)(cid:165)(cid:109) III. JAK TO ZBUDOWA(cid:109)? KODOWANIE ZGODNE Z BDD ..............219
Rozdzia(cid:239) 7. Od wykonywalnych specyfikacji do solidnych automatycznych
testów akceptacyjnych 223
Pisanie niezawodnych testów akceptacji 225
7.1.
7.2. Automatyzowanie procesu konfiguracji testu 228
Poleć książkęKup książkęSpis tre(cid:258)ci
7
7.2.1.
7.2.2.
7.2.3.
7.2.4.
7.2.5.
Inicjowanie bazy danych przed ka(cid:285)dym testem 228
Inicjowanie bazy danych na pocz(cid:200)tku zestawu testów 229
Korzystanie z haków inicjalizacji 229
Konfigurowanie danych specyficznych dla scenariusza 233
U(cid:285)ycie person i znanych encji 235
7.3. Oddzielenie warstwy „co” od warstwy „jak” 237
7.3.1. Warstwa regu(cid:239) biznesowych opisuje oczekiwane rezultaty 238
7.3.2. Warstwa przep(cid:239)ywu pracy opisuje dzia(cid:239)ania u(cid:285)ytkownika 239
7.3.3. Warstwa techniczna realizuje interakcje z systemem 241
7.3.4.
Podsumowanie 243
Ile warstw? 242
7.4.
Rozdzia(cid:239) 8. Automatyzacja kryteriów akceptacji
dla warstwy interfejsu u(cid:285)ytkownika 245
8.1. Kiedy i jak nale(cid:285)y testowa(cid:202) interfejs u(cid:285)ytkownika? 247
8.1.1.
8.1.2.
8.1.3.
Zagro(cid:285)enie zbyt wieloma testami webowymi 247
Testy webowe z przegl(cid:200)darkami w trybie headless 248
Ile testów webowych naprawd(cid:218) potrzebujemy? 250
8.2. Automatyzowanie webowych kryteriów akceptacji
z wykorzystaniem programu Selenium WebDriver 251
8.2.1.
8.2.2.
8.2.3.
8.2.4.
8.2.5.
Pierwsze kroki z WebDriver w Javie 252
Identyfikacja elementów strony WWW 255
Interakcje z elementami stron WWW 263
Praca ze stronami asynchronicznymi i testowanie aplikacji AJAX 265
Pisanie aplikacji webowych „przyjaznych dla testów” 267
8.3. Korzystanie z obiektów stron w celu poprawy czytelno(cid:258)ci testów 267
8.3.1. Wprowadzenie do wzorca Obiekty stron 268
8.3.2.
8.3.3.
Podsumowanie 281
Pisanie dobrze zaprojektowanych obiektów stron 273
Korzystanie z bibliotek rozszerzaj(cid:200)cych bibliotek(cid:218) WebDriver 279
8.4.
Rozdzia(cid:239) 9. Automatyzacja kryteriów akceptacji
dla wymaga(cid:241) niekorzystaj(cid:200)cych z UI 283
9.1. Równowaga pomi(cid:218)dzy testami akceptacyjnymi z wykorzystaniem UI i bez UI 285
9.2. Kiedy u(cid:285)ywa(cid:202) testów akceptacji bez po(cid:258)rednictwa UI 286
9.3. Typy automatycznych testów akceptacji niekorzystaj(cid:200)cych z UI 290
9.3.1.
9.3.2.
9.3.3.
Testowanie z wykorzystaniem warstwy kontrolera 291
Bezpo(cid:258)rednie testowanie logiki biznesowej 295
Testowanie warstwy us(cid:239)ug 299
9.4. Definiowanie i testowanie wymaga(cid:241) niefunkcjonalnych 304
9.5. Odkrywanie projektu 306
9.6.
Podsumowanie 308
Poleć książkęKup książkę8
Spis tre(cid:258)ci
Rozdzia(cid:239) 10. BDD a testy jednostkowe 309
10.1. BDD, TDD a testy jednostkowe 310
10.1.1. BDD dotyczy pisania specyfikacji, a nie testów,
na wszystkich poziomach 312
10.1.2. BDD bazuje na ugruntowanych praktykach TDD 313
10.1.3. Narz(cid:218)dzia BDD do testów jednostkowych 313
10.2. Od kryteriów akceptacji do zaimplementowanych cech funkcjonalnych 313
Zaczynamy od wysokopoziomowego kryterium akceptacji 316
10.2.1. BDD sprzyja stosowaniu podej(cid:258)cia „z zewn(cid:200)trz do wewn(cid:200)trz” 314
10.2.2.
10.2.3. Automatyzacja scenariuszy kryteriów akceptacji 317
10.2.4.
10.2.5.
10.2.6.
10.2.7. Wykorzystanie kodu definicji kroku do wyspecyfikowania
Implementacja definicji kroków 317
Zrozumienie modelu domeny 318
Pisanie kodu, który chcieliby(cid:258)my mie(cid:202) 319
i zaimplementowania kodu aplikacji 319
10.2.8. W jaki sposób stosowanie praktyk BDD pomog(cid:239)o? 324
10.3. Analiza niskopoziomowych wymaga(cid:241), odkrywanie projektu
i implementacja bardziej z(cid:239)o(cid:285)onych funkcjonalno(cid:258)ci 325
10.3.1. Wykorzystanie kodu definicji kroku do analizy niskopoziomowego
projektu 326
Praca z tabelami przyk(cid:239)adów 328
10.3.2.
10.3.3. Odkrywanie nowych klas i us(cid:239)ug w miar(cid:218) implementowania kodu
produkcyjnego 330
10.3.4. Natychmiastowa implementacja prostych klas lub metod 331
10.3.5. Wykorzystanie minimalnej implementacji 331
10.3.6. Wykorzystanie namiastek i makiet w celu odroczenia implementacji
bardziej z(cid:239)o(cid:285)onego kodu 332
10.3.7. Rozwijanie niskopoziomowych specyfikacji technicznych 333
10.4. Narz(cid:218)dzia, dzi(cid:218)ki którym testy jednostkowe BDD staj(cid:200) si(cid:218) (cid:239)atwiejsze 336
10.4.1.
10.4.2.
10.4.3.
Stosowanie praktyk BDD z tradycyjnymi narz(cid:218)dziami testów
jednostkowych 336
Pisanie specyfikacji, a nie testów — rodzina RSpec 339
Pisanie bardziej ekspresywnych specyfikacji z wykorzystaniem
narz(cid:218)dzi Spock albo Spec2 343
10.5. U(cid:285)ywanie wykonywalnych specyfikacji jako dynamicznej dokumentacji 345
10.5.1. U(cid:285)ywanie p(cid:239)ynnego kodowania w celu poprawy czytelno(cid:258)ci 346
10.5.2.
10.5.3.
P(cid:239)ynne asercje w j(cid:218)zyku JavaScript 347
P(cid:239)ynne asercje w j(cid:218)zykach statycznych 347
10.6. Podsumowanie 349
CZ(cid:125)(cid:165)(cid:109) IV. ZAAWANSOWANE ASPEKTY BDD ............................................349
Rozdzia(cid:239) 11. Dynamiczna dokumentacja — raportowanie a zarz(cid:200)dzanie
projektem 353
11.1. Dynamiczna dokumentacja — widok wysokopoziomowy 354
11.2. Czy osi(cid:200)gn(cid:218)li(cid:258)my cel? Raporty dotycz(cid:200)ce gotowo(cid:258)ci
i pokrycia cech funkcjonalnych 356
Poleć książkęKup książkęSpis tre(cid:258)ci
9
11.2.1. Gotowo(cid:258)(cid:202) cech funkcjonalnych — jakie cechy s(cid:200) gotowe
11.2.2.
do dostarczenia 356
Pokrycie cechy funkcjonalnej — jakie wymagania zosta(cid:239)y spe(cid:239)nione 357
11.3. Integracja z cyfrowym rejestrem projektu 360
11.4. Organizowanie dynamicznej dokumentacji 362
11.4.1. Organizowanie dynamicznej dokumentacji
wed(cid:239)ug wysokopoziomowych wymaga(cid:241) 363
11.4.2. Organizowanie dynamicznej dokumentacji z wykorzystaniem tagów 364
11.4.3. Dynamiczna dokumentacja do tworzenia raportów
na temat publikacji oprogramowania 364
11.5. Dostarczanie dokumentacji w lu(cid:283)niejszej formie 366
11.6. Techniczna dynamiczna dokumentacja 368
11.6.1. Testy jednostkowe jako dynamiczna dokumentacja 369
11.6.2. Dynamiczna dokumentacja dla starszych aplikacji 371
11.7. Podsumowanie 372
Rozdzia(cid:239) 12. BDD w procesie budowania 373
12.1. Wykonywalne specyfikacje powinny by(cid:202) cz(cid:218)(cid:258)ci(cid:200) automatycznego
procesu budowy 374
12.1.1. Ka(cid:285)da specyfikacja powinna by(cid:202) samowystarczalna 375
12.1.2. Wykonywalne specyfikacje powinny by(cid:202) przechowywane
12.1.3.
w systemie kontroli wersji 376
Powinna istnie(cid:202) mo(cid:285)liwo(cid:258)(cid:202) uruchomienia wykonywalnych specyfikacji
z wiersza polecenia 377
12.2. Ci(cid:200)g(cid:239)a integracja przyspiesza cykl sprz(cid:218)(cid:285)enia zwrotnego 378
12.3. Ci(cid:200)g(cid:239)e dostawy — ka(cid:285)da kompilacja jest potencjaln(cid:200) wersj(cid:200)
do opublikowania 380
12.4. Strategia ci(cid:200)g(cid:239)ej integracji w celu wdra(cid:285)ania dynamicznej dokumentacji 383
Publikowanie dynamicznej dokumentacji na serwerze kompilacji 384
Publikowanie dynamicznej dokumentacji na dedykowanym
serwerze WWW 385
12.4.1.
12.4.2.
12.5. Szybsze zautomatyzowane kryteria akceptacji 385
12.5.1. Uruchamianie równoleg(cid:239)ych testów akceptacyjnych
w obr(cid:218)bie zautomatyzowanego procesu budowy 386
12.5.2. Uruchamianie równoleg(cid:239)ych testów na wielu maszynach 388
12.5.3. Uruchamianie równoleg(cid:239)ych testów webowych
z wykorzystaniem Selenium Grid 391
12.6. Podsumowanie 395
12.7. Ostatnie s(cid:239)owa 396
Skorowidz 399
Poleć książkęKup książkę10
Spis tre(cid:258)ci
Poleć książkęKup książkęBDD z lotu ptaka
W tym rozdziale:
(cid:81) Wyczerpuj(cid:261)cy przegl(cid:261)d praktyk BDD w akcji.
(cid:81) Odkrywanie cech funkcjonalnych i opisywanie
ich za pomoc(cid:261) historyjek i przyk(cid:225)adów.
(cid:81) Wykorzystanie wykonywalnych specyfikacji
do szczegó(cid:225)owego opisywania cech.
(cid:81) Wykorzystanie niskopoziomowych praktyk BDD
do implementacji cech funkcjonalnych.
(cid:81) Wykorzystanie wyników testów BDD jako dynamicznej
dokumentacji.
(cid:81) Wykorzystanie dynamicznej dokumentacji w celu
wsparcia bie(cid:298)(cid:261)cego utrzymania aplikacji.
W tym rozdziale przeanalizujemy konkretny przyk(cid:239)ad wykorzystania praktyk BDD
w rzeczywistym projekcie. Jak dowiedzieli(cid:258)my si(cid:218) z poprzedniego rozdzia(cid:239)u, stosowa-
nie praktyk BDD wi(cid:200)(cid:285)e si(cid:218) z zaanga(cid:285)owaniem zespo(cid:239)u rozwojowego w czasie trwania
ca(cid:239)ego projektu w rozmowy z klientem, a tak(cid:285)e z wykorzystaniem przyk(cid:239)adów do budo-
wania bardziej konkretnego i jednoznacznego zrozumienia realnych potrzeb firmy. Spe-
cyfikacje s(cid:200) budowane w formie wykonywalnej. Mo(cid:285)na je wykorzysta(cid:202) do okre(cid:258)lenia
wymaga(cid:241) dotycz(cid:200)cych oprogramowania, kierowania ich implementacj(cid:200) oraz weryfiko-
wania poprawno(cid:258)ci dostarczanego produktu. Mo(cid:285)na równie(cid:285) stosowa(cid:202) te techniki pod-
czas bardziej wysokopoziomowej analizy wymaga(cid:241). Ich wykorzystanie pozwala skupi(cid:202)
si(cid:218) na tych mo(cid:285)liwo(cid:258)ciach i funkcjach aplikacji, które przynios(cid:200) rzeczywist(cid:200) warto(cid:258)(cid:202) dla
biznesu.
Poleć książkęKup książkę58
ROZDZIA(cid:224) 2. BDD z lotu ptaka
Kluczowym elementem tej praktyki jest okre(cid:258)lanie scenariuszy lub konkretnych
przyk(cid:239)adów sposobu dzia(cid:239)ania okre(cid:258)lonej funkcji lub zdefiniowanej historyjki u(cid:285)ytkow-
nika. Scenariusze te pomagaj(cid:200) zweryfikowa(cid:202) poprawno(cid:258)(cid:202) rozumienia problemu i roz-
szerzy(cid:202) wiedz(cid:218) na jego temat. S(cid:200) one równie(cid:285) doskona(cid:239)ym narz(cid:218)dziem komunikacji.
Stanowi(cid:200) fundament kryteriów akceptacji, które mo(cid:285)na pó(cid:283)niej zintegrowa(cid:202) z procesem
kompilacji w formie automatycznych testów akceptacyjnych. W po(cid:239)(cid:200)czeniu z automa-
tycznymi testami akceptacyjnymi te przyk(cid:239)ady steruj(cid:200) procesem rozwoju. Pomagaj(cid:200)
projektantom przygotowa(cid:202) projekt skutecznego i funkcjonalnego interfejsu u(cid:285)yt-
kownika oraz wspieraj(cid:200) deweloperów w odkrywaniu podstawowych zachowa(cid:241), które
trzeba zaimplementowa(cid:202), aby dostarczy(cid:202) wymagane cechy funkcjonalne.
W pozosta(cid:239)ej cz(cid:218)(cid:258)ci tego rozdzia(cid:239)u przyjrzymy si(cid:218) praktycznemu przyk(cid:239)adowi zasto-
sowania tego procesu. W opisie uwzgl(cid:218)dnimy aspekty ca(cid:239)ego cyklu rozwoju — od ana-
lizy biznesowej a(cid:285) do implementacji, testowania i utrzymania kodu.
2.1. Wprowadzenie w tematyk(cid:266) aplikacji
rozk(cid:225)adu jazdy poci(cid:261)gów
Aby zilustrowa(cid:202) przyk(cid:239)adem tematyk(cid:218) omawian(cid:200) w niniejszym rozdziale, za(cid:239)ó(cid:285)my, (cid:285)e
pracujesz dla du(cid:285)ej rz(cid:200)dowej agencji transportu publicznego. Poproszono Ci(cid:218), aby(cid:258)
pokierowa(cid:239) niewielkim zespo(cid:239)em maj(cid:200)cym za zadanie stworzenie us(cid:239)ugi, która dostar-
czy danych na temat rozk(cid:239)adu jazdy poci(cid:200)gów oraz w czasie rzeczywistym zapewni dane
o opó(cid:283)nieniach, pracach nad trakcj(cid:200) itp. Us(cid:239)uga ta ma by(cid:202) dost(cid:218)pna dla ró(cid:285)nych apli-
kacji mobilnych u(cid:285)ywanych przez osoby doje(cid:285)d(cid:285)aj(cid:200)ce do pracy. Sie(cid:202) kolejow(cid:200), któr(cid:200)
wykorzystamy w przyk(cid:239)adzie, pokazano na rysunku 2.1.
W dziale w(cid:239)a(cid:258)nie wdro(cid:285)ono praktyki Agile i BDD, zaczynasz wi(cid:218)c od rozmowy z klu-
czowymi interesariuszami, aby upewni(cid:202) si(cid:218), (cid:285)e Ty i Twój zespó(cid:239) macie czytelny obraz
celów biznesowych steruj(cid:200)cych projektem. To pomo(cid:285)e zespo(cid:239)owi dostarczy(cid:202) lepsz(cid:200),
bardziej ukierunkowan(cid:200) aplikacj(cid:218).
Gdy cele biznesowe zostan(cid:200) zrozumiane i wyartyku(cid:239)owane, trzeba b(cid:218)dzie pracowa(cid:202)
razem z analitykami biznesowymi i przedstawicielami biznesowymi w celu podj(cid:218)cia
decyzji dotycz(cid:200)cej cech funkcjonalnych oprogramowania, za pomoc(cid:200) których b(cid:218)dzie
mo(cid:285)na osi(cid:200)gn(cid:200)(cid:202) te cele. Cechy te s(cid:200) wymaganiami wysokiego poziomu w postaci: „zapew-
nienie podró(cid:285)nym optymalnej trasy pomi(cid:218)dzy stacjami” lub „powiadamianie podró(cid:285)nych
o opó(cid:283)nieniach poci(cid:200)gu”.
Prawdopodobnie nie uda si(cid:218) zrealizowa(cid:202) tak obszernych cech funkcjonalnych w jed-
nym kawa(cid:239)ku, dlatego trzeba je rozbi(cid:202) na mniejsze jednostki, znane w(cid:258)ród zespo(cid:239)ów
praktykuj(cid:200)cych metodyk(cid:218) Agile jako historyjki. Historyjki mog(cid:200) obejmowa(cid:202) takie dzia-
(cid:239)ania, jak „znajd(cid:283) optymaln(cid:200) tras(cid:218) mi(cid:218)dzy stacjami na tej samej linii” lub „znajd(cid:283) opty-
maln(cid:200) tras(cid:218) mi(cid:218)dzy stacjami na ró(cid:285)nych liniach”.
Przyst(cid:218)puj(cid:200)c do implementacji historyjki, spotka(cid:239)e(cid:258) si(cid:218) z analitykiem biznesowym,
programist(cid:200) i testerem, aby opisa(cid:202) t(cid:218) historyjk(cid:218) za pomoc(cid:200) konkretnych przyk(cid:239)adów.
Wiele z tych przyk(cid:239)adów zosta(cid:239)o wcze(cid:258)niej omówionych z przedstawicielami biznesu.
Przyk(cid:239)ady te stan(cid:200) si(cid:218) kryteriami akceptacji dla historyjki. S(cid:200) one wyra(cid:285)one w formal-
nym stylu BDD, który pó(cid:283)niej mo(cid:285)na zautomatyzowa(cid:202):
Poleć książkęKup książkę2.1. Wprowadzenie w tematyk(cid:218) aplikacji rozk(cid:239)adu jazdy poci(cid:200)gów
59
Rysunek 2.1. Fragment sieci kolejowej w Sydney
Zak(cid:273)adaj(cid:230)c poci(cid:230)gi linii Western odje(cid:318)d(cid:318)aj(cid:230) z Parramatta o 7:58, 8:02, 8:08, 8:11
Gdy chc(cid:250) podró(cid:318)owa(cid:232) z Parramatta do Town Hall o 8:00
Wtedy powinienem uzyska(cid:232) informacj(cid:250), (cid:318)e nale(cid:318)y wsi(cid:230)(cid:295)(cid:232) w poci(cid:230)g o 8:02
Wspomniane kryteria akceptacji spe(cid:239)niaj(cid:200) rol(cid:218) punktu wyj(cid:258)cia dla prac rozwojowych.
Ze wzgl(cid:218)du na to, (cid:285)e do prowadzenia projektów programistycznych w Twoim dziale jest
wykorzystywany j(cid:218)zyk Java, kryteria akceptacji b(cid:218)d(cid:200) zautomatyzowane za pomoc(cid:200)
narz(cid:218)dzia Javy o nazwie JBehave, natomiast kod aplikacji b(cid:218)dzie napisany w Javie.
Podczas tworzenia cechy b(cid:218)dziemy korzysta(cid:202) z bardziej niskopoziomowego narz(cid:218)-
dzia BDD do testów jednostkowych o nazwie Spock. Narz(cid:218)dzie to pomo(cid:285)e zaprojekto-
wa(cid:202) i udokumentowa(cid:202) implementacj(cid:218) oraz sprawdzi(cid:202) jej poprawno(cid:258)(cid:202).
B(cid:218)d(cid:200) równie(cid:285) generowane raporty z testów i tworzona dynamiczna dokumentacja
na podstawie zautomatyzowanych kryteriów akceptacji. W ten sposób zilustrujemy te
funkcje, które ju(cid:285) zosta(cid:239)y wykonane, oraz zaprezentujemy sposób ich dzia(cid:239)ania.
Celem niniejszego rozdzia(cid:239)u jest zaprezentowanie koncepcji podej(cid:258)cia oraz zapo-
znanie z niektórymi z u(cid:285)ywanych technologii. Nie jest nim natomiast zaprezentowanie
kompletnego dzia(cid:239)aj(cid:200)cego przyk(cid:239)adu u(cid:285)ycia konkretnego stosu technologii. Zamie(cid:258)cimy
jednak wystarczaj(cid:200)co du(cid:285)o szczegó(cid:239)ów technicznych do tego, by by(cid:239)a mo(cid:285)liwa analiza
przyk(cid:239)adu. W kolejnych rozdzia(cid:239)ach przyjrzymy si(cid:218) znacznie dok(cid:239)adniej ka(cid:285)demu
z zagadnie(cid:241) poruszanych w tym rozdziale, a tak(cid:285)e wielu innym.
Poleć książkęKup książkę60
ROZDZIA(cid:224) 2. BDD z lotu ptaka
2.2. Okre(cid:286)lenie korzy(cid:286)ci
ze stosowania proponowanej aplikacji
Jednym z kluczowych celów stosowania praktyk BDD jest zadbanie o to, aby wszyscy
uczestnicy projektu dok(cid:239)adnie rozumieli, co projekt stara si(cid:218) zrealizowa(cid:202), a tak(cid:285)e znali
jego podstawowe cele biznesowe. To samo w sobie sprowadza si(cid:218) do zapewnienia zre-
alizowania tych celów przez aplikacj(cid:218).
Mo(cid:285)na to osi(cid:200)gn(cid:200)(cid:202) w wyniku wspó(cid:239)pracy z u(cid:285)ytkownikami i innymi interesariu-
szami w celu zdefiniowania lub wyja(cid:258)nienia wysokopoziomowych celów biznesowych
aplikacji. Cele te powinny dostarcza(cid:202) zwi(cid:218)z(cid:239)ej wizji tego, co potrzebujemy stworzy(cid:202).
Cele biznesowe dotycz(cid:200) dostarczania warto(cid:258)ci, powszechnie stosuje si(cid:218) wi(cid:218)c wyra(cid:285)anie
ich w kategoriach zwi(cid:218)kszonych lub bezpiecznych dochodów lub obni(cid:285)enia kosztów.
W tym przypadku celem aplikacji, któr(cid:200) budujemy, jest dostarczenie podró(cid:285)nym
rozk(cid:239)adów poci(cid:200)gów i aktualizacji w czasie rzeczywistym. Podstawowy cel biznesowy tej
aplikacji mo(cid:285)na wyrazi(cid:202) w nast(cid:218)puj(cid:200)cy sposób:
Zwi(cid:250)kszenie przychodów ze sprzeda(cid:318)y biletów dzi(cid:250)ki u(cid:273)atwieniu podró(cid:318)y poci(cid:230)giem
(cid:180)i zwi(cid:250)kszenie wydajno(cid:295)ci takiego sposobu podró(cid:318)owania
Zrozumienie i zdefiniowanie celów aplikacji znacznie u(cid:239)atwia ustalenie wzgl(cid:218)dnej war-
to(cid:258)ci planowanej cechy funkcjonalnej. Na przyk(cid:239)ad cecha funkcjonalna, która powiada-
mia podró(cid:285)nych o spó(cid:283)nieniu ich poci(cid:200)gu, przyczynia si(cid:218) do ogólnego celu, poniewa(cid:285)
daje podró(cid:285)nym mo(cid:285)liwo(cid:258)(cid:202) odpowiedniej zmiany planów. Z drugiej strony, cecha, która
pozwala podró(cid:285)nym ocenia(cid:202) poszczególne stacje kolejowe, mo(cid:285)e by(cid:202) uznana za niezbyt
warto(cid:258)ciow(cid:200).
2.3. Analiza wymaga(cid:276) — odkrywanie i zrozumienie funkcji
Kiedy u(cid:258)wiadomimy sobie wysokopoziomowe cele aplikacji, mo(cid:285)emy zacz(cid:200)(cid:202) wspó(cid:239)prac(cid:218)
z interesariuszami, aby okre(cid:258)li(cid:202) dok(cid:239)adnie, czego potrzebuj(cid:200), (cid:285)eby osi(cid:200)gn(cid:200)(cid:202) te cele.
Zazwyczaj polega to na zdefiniowaniu zestawu cech funkcjonalnych, które nale(cid:285)y zaim-
plementowa(cid:202) w aplikacji w celu dostarczenia warto(cid:258)ci, których poszukujemy.
Dla potrzeb niniejszego rozdzia(cid:239)u za(cid:239)ó(cid:285)my, (cid:285)e uzgodnili(cid:258)my z zainteresowanymi
stronami nast(cid:218)puj(cid:200)ce kluczowe cechy funkcjonalne:
(cid:81) Zaproponowanie podró(cid:285)nym optymalnej trasy.
(cid:81) Zapewnienie podró(cid:285)nym w czasie rzeczywistym informacji na temat opó(cid:283)nie(cid:241)
w formie zestawienia.
(cid:81) Umo(cid:285)liwienie podró(cid:285)nym nagrywania swoich ulubionych podró(cid:285)y.
(cid:81) Powiadamianie podró(cid:285)nych o opó(cid:283)nieniach ich poci(cid:200)gu.
Przyjrzyjmy si(cid:218), jak mo(cid:285)na opisa(cid:202) niektóre z tych cech.
2.3.1. Opisywanie funkcji
Po uzyskaniu ogólnego poj(cid:218)cia o cechach funkcjonalnych, które chcemy dostarczy(cid:202),
nale(cid:285)y opisa(cid:202) je bardziej szczegó(cid:239)owo. Istnieje wiele sposobów opisywania wymaga(cid:241).
Poleć książkęKup książkę2.3. Analiza wymaga(cid:241) — odkrywanie i zrozumienie funkcji
61
Zespo(cid:239)y stosuj(cid:200)ce metodologi(cid:218) Agile zazwyczaj pisz(cid:200) krótki zarys wymagania w for-
macie na tyle zwi(cid:218)z(cid:239)ym, aby zmie(cid:258)ci(cid:239) si(cid:218) na pojedynczej karcie katalogowej1. Zespo(cid:239)y
korzystaj(cid:200)ce z praktyk BDD cz(cid:218)sto u(cid:285)ywaj(cid:200) nast(cid:218)puj(cid:200)cego formatu:
Jakie cele biznesowe staramy si(cid:266) osi(cid:261)gn(cid:261)(cid:252)?
Kto tego potrzebuje?
Co trzeba zrobi(cid:252), aby umo(cid:298)liwi(cid:252) osi(cid:261)gni(cid:266)cie tego celu?
W celu osi(cid:230)gni(cid:250)cia celu biznesowego lub dostarczenia warto(cid:295)ci biznesowej
Jako interesariusz
Chc(cid:250) czego(cid:295)
Kolejno(cid:258)(cid:202) w tym przypadku ma znaczenie. Podczas planowania cechy funkcjonalnej
i historii g(cid:239)ównym celem powinno by(cid:202) dostarczenie warto(cid:258)ci biznesowej. Nale(cid:285)y roz-
pocz(cid:200)(cid:202) od okre(cid:258)lenia warto(cid:258)ci biznesowej, jak(cid:200) staramy si(cid:218) dostarczy(cid:202)
, nast(cid:218)pnie
, i na koniec wymieniamy cech(cid:218)
podajemy, kto potrzebuje funkcji, któr(cid:200) proponujemy
funkcjonaln(cid:200), która b(cid:218)dzie wspomaga(cid:202) osi(cid:200)gni(cid:218)cie tego celu
Taki sposób opisywania pomaga uzyska(cid:202) pewno(cid:258)(cid:202), (cid:285)e ka(cid:285)da cecha funkcjonalna
aktywnie przyczynia si(cid:218) do osi(cid:200)gni(cid:218)cia celu biznesowego, a to zmniejsza ryzyko wyst(cid:200)-
pienia niekontrolowanego rozrastania si(cid:218) zakresu projektu (ang. scope creep). Taki opis
spe(cid:239)nia równie(cid:285) rol(cid:218) wygodnego przypomnienia powodów, dla których implementujemy
t(cid:218) cech(cid:218). Na przyk(cid:239)ad mo(cid:285)na powiedzie(cid:202) co(cid:258) takiego:
.
W celu bardziej efektywnego planowania podró(cid:318)y
Jako podró(cid:318)ny
Chc(cid:250) zna(cid:232) optymaln(cid:230) tras(cid:250) pomi(cid:250)dzy dwoma stacjami
Co cecha funkcjonalna b(cid:266)dzie robi(cid:252)?
To nie jest jedyna mo(cid:285)liwo(cid:258)(cid:202). Wiele zespo(cid:239)ów u(cid:285)ywa szablonów popularnych we
wcze(cid:258)niejszych podej(cid:258)ciach Agile:
Kto jest zainteresowany tak(cid:261) cech(cid:261)?
Jak(cid:261) warto(cid:286)(cid:252) biznesow(cid:261)
staramy si(cid:266) dostarczy(cid:252)?
Kto skorzysta z tej cechy; kto jej chce?
Jako interesariusz
Chc(cid:250) czego(cid:295)
Tak, abym móg(cid:273) osi(cid:230)gn(cid:230)(cid:232) pewien cel biznesowy
Co cecha funkcjonalna robi?
Jakie warto(cid:286)ci biznesowe
interesariusze uzyskaj(cid:261)
przez t(cid:266) cech(cid:266) funkcjonaln(cid:261)?
odnosi si(cid:218) do osoby u(cid:285)ywaj(cid:200)cej cechy funkcjonalnej
Ta odmiana opisu ma pomóc deweloperom zrozumie(cid:202) kontekst wymagania w katego-
riach tego, kto b(cid:218)dzie u(cid:285)ywa(cid:239) cechy funkcjonalnej i czego od niej oczekuje. Interesa-
lub osoby zaintereso-
riusz
identyfikuje powód, dla którego ta
wanej wynikiem jej dzia(cid:239)ania. Cel biznesowy
cecha jest potrzebna, i warto(cid:258)(cid:202), jak(cid:200) ma ona zapewni(cid:202). Odpowiednikiem opisu cechy
funkcjonalnej podanego wcze(cid:258)niej mo(cid:285)e by(cid:202) nast(cid:218)puj(cid:200)cy opis:
Jako podró(cid:318)ny
Chc(cid:250) zna(cid:232) najlepszy sposób podró(cid:318)owania pomi(cid:250)dzy dwoma stacjami
Tak, abym móg(cid:273) szybko dotrze(cid:232) do celu podró(cid:318)y
Oba te formaty s(cid:200) wygodnymi konwencjami, ale nie istnieje obowi(cid:200)zek wybrania jed-
nego lub drugiego formatu, pod warunkiem (cid:285)e pami(cid:218)tamy o jasnym wyra(cid:285)eniu korzy(cid:258)ci
1 Te karty katalogowe mog(cid:200) by(cid:202) pó(cid:283)niej u(cid:285)yte do zaplanowania i wizualizacji post(cid:218)pów.
2 Taki format zosta(cid:239) pierwotnie zaproponowany przez Chrisa Mattsa w kontek(cid:258)cie wstrzykiwania
funkcjonalno(cid:258)ci — zagadnienia, któremu przyjrzymy si(cid:218) w nast(cid:218)pnym rozdziale.
Poleć książkęKup książkę62
ROZDZIA(cid:224) 2. BDD z lotu ptaka
biznesowych. Na przyk(cid:239)ad, niektórzy do(cid:258)wiadczeni praktycy ch(cid:218)tnie korzystaj(cid:200) z notacji
„W celu... Jako... Chc(cid:218)” do opisania takich cech wysokopoziomowych, w których k(cid:239)a-
dziemy nacisk na warto(cid:258)ci biznesowe, jakie system powinien dostarczy(cid:202), natomiast do
okre(cid:258)lenia bardziej szczegó(cid:239)owych historyjek u(cid:285)ytkowników w ramach cechy funkcjo-
nalnej, gdy historie dotycz(cid:200) wyra(cid:283)nie dostarczania warto(cid:258)ci dla poszczególnych u(cid:285)yt-
kowników w ramach tej cechy, stosuj(cid:200) konwencj(cid:218) „Jako... Chc(cid:218)... Tak, aby”.
2.3.2. Podzia(cid:225) cech funkcjonalnych na historyjki
Cecha funkcjonalna czasami jest sformu(cid:239)owana wystarczaj(cid:200)co szczegó(cid:239)owo, aby mo(cid:285)na
by(cid:239)o przyst(cid:200)pi(cid:202) do jej realizacji od razu, ale cz(cid:218)sto trzeba j(cid:200) podzieli(cid:202) na mniejsze frag-
menty. W projektach Agile wi(cid:218)ksze cechy funkcjonalne cz(cid:218)sto s(cid:200) dzielone na histo-
ryjki u(cid:285)ytkownika. Ka(cid:285)da historyjka dotyczy odr(cid:218)bnego aspektu problemu i jest wystar-
czaj(cid:200)co zwi(cid:218)z(cid:239)a, aby mo(cid:285)na j(cid:200) by(cid:239)o dostarczy(cid:202) w pojedynczej iteracji.
Na przyk(cid:239)ad funkcja „zaproponowanie podró(cid:285)nym optymalnej trasy” mo(cid:285)e by(cid:202) zbyt
du(cid:285)a, aby stworzy(cid:202) j(cid:200) za jednym razem (z punktu widzenia deweloperów znalezienie
trasy obejmuj(cid:200)ce (cid:239)(cid:200)czenie kilku poci(cid:200)gów to skomplikowana operacja). Ponadto, by(cid:202)
mo(cid:285)e przed zbudowaniem ca(cid:239)ej cechy funkcjonalnej chcieliby(cid:258)my uzyska(cid:202) jakie(cid:258) opi-
nie na temat projektu interfejsu u(cid:285)ytkownika. T(cid:218) cech(cid:218) mo(cid:285)na podzieli(cid:202) na mniejsze
historyjki, na przyk(cid:239)ad:
(cid:81) Znajd(cid:283) optymaln(cid:200) tras(cid:218) pomi(cid:218)dzy stacjami na tej samej linii.
(cid:81) Dowiedz si(cid:218), o której godzinie odje(cid:285)d(cid:285)aj(cid:200) nast(cid:218)pne poci(cid:200)gi do stacji docelowej.
(cid:81) Znajd(cid:283) optymaln(cid:200) tras(cid:218) pomi(cid:218)dzy stacjami na ró(cid:285)nych liniach.
Mo(cid:285)na opisa(cid:202) te historyjki troch(cid:218) bardziej szczegó(cid:239)owo, stosuj(cid:200)c ten sam format, któ-
rego u(cid:285)ywali(cid:258)my w odniesieniu do funkcji:
Historyjka: Znajd(cid:316) optymaln(cid:230) tras(cid:250) pomi(cid:250)dzy stacjami na tej samej linii.
W celu dotarcia do miejsca docelowego na czas
Jako podró(cid:318)ny
Chc(cid:250) si(cid:250) dowiedzie(cid:232), do jakiego poci(cid:230)gu powinienem wsi(cid:230)(cid:295)(cid:232)
Historyjka: Dowiedz si(cid:250), o której godzinie odje(cid:318)d(cid:318)aj(cid:230) nast(cid:250)pne poci(cid:230)gi do stacji docelowej
W celu bardziej efektywnego planowania podró(cid:318)y
Jako podró(cid:318)ny
Chc(cid:250) si(cid:250) dowiedzie(cid:232), jakie nast(cid:250)pne poci(cid:230)gi odje(cid:318)d(cid:318)aj(cid:230) do mojej stacji docelowej
Historyjka: Znajd(cid:316) optymaln(cid:230) tras(cid:250) pomi(cid:250)dzy stacjami na ró(cid:318)nych liniach
W celu dotarcia do miejsca docelowego na czas
Jako podró(cid:318)ny
Chc(cid:250) si(cid:250) dowiedzie(cid:232), do jakiego poci(cid:230)gu powinienem wsi(cid:230)(cid:295)(cid:232)
Oraz uzyska(cid:232) szczegó(cid:273)owe informacje na temat potrzebnych po(cid:273)(cid:230)cze(cid:275)
Zwró(cid:202)my uwag(cid:218), (cid:285)e pokazana lista historyjek w (cid:285)adnym razie nie jest sztywnym zbio-
rem specyfikacji, pod którym powinni si(cid:218) podpisa(cid:202) u(cid:285)ytkownicy i deweloperzy. Defi-
niowanie historyjek jest dynamicznym, iteracyjnym procesem maj(cid:200)cym na celu u(cid:239)atwie-
nie komunikacji i zapewnienie wspólnego zrozumienia przestrzeni problemu. Podczas
implementowania poszczególnych historyjek mo(cid:285)emy uzyska(cid:202) opinie od interesariuszy.
Na podstawie tych opinii mo(cid:285)na u(cid:258)ci(cid:258)li(cid:202) inne historyjki, usun(cid:200)(cid:202) niektóre z nich b(cid:200)d(cid:283)
Poleć książkęKup książkę2.3. Analiza wymaga(cid:241) — odkrywanie i zrozumienie funkcji
63
doda(cid:202) nowe, które w inny sposób mog(cid:200) przyczyni(cid:202) si(cid:218) do osi(cid:200)gni(cid:218)cia celów bizneso-
wych. Odkrywanie funkcji i tworzenie historyjek jest ci(cid:200)g(cid:239)ym procesem poznawania
przestrzeni problemu.
2.3.3. Ilustrowanie historyjek przyk(cid:225)adami
Po zidentyfikowaniu pewnego zbioru warto(cid:258)ciowych cech funkcjonalnych i historyjek
mo(cid:285)emy przyst(cid:200)pi(cid:202) do analizowania ich w sposób bardziej szczegó(cid:239)owy. Bardzo skutecz-
nym sposobem, aby to zrobi(cid:202), jest poproszenie u(cid:285)ytkowników i innych interesariuszy
o podanie konkretnych przyk(cid:239)adów.
Kiedy u(cid:285)ytkownik pyta nas o cech(cid:218) funkcjonaln(cid:200), cz(cid:218)sto od razu zaczynamy budo-
wa(cid:202) koncepcyjny model problemu, który nale(cid:285)y rozwi(cid:200)za(cid:202). Je(cid:258)li b(cid:218)dziemy post(cid:218)powa(cid:202)
w ten sposób, nasze zrozumienie problemu mo(cid:285)e by(cid:202) (cid:239)atwo zak(cid:239)ócone przez niejawne
i niewypowiedziane za(cid:239)o(cid:285)enia. To mo(cid:285)e doprowadzi(cid:202) do stworzenia niedok(cid:239)adnego
modelu mentalnego, a nast(cid:218)pnie do b(cid:239)(cid:218)dnej implementacji. Poproszenie interesariuszy
o konkretne przyk(cid:239)ady tego, co maj(cid:200) na my(cid:258)li, to (cid:258)wietny sposób sprawdzenia i potwier-
dzenia w(cid:239)a(cid:258)ciwego zrozumienia problemu.
Na przyk(cid:239)ad pomi(cid:218)dzy Tob(cid:200) a Jerzym, ekspertem w dziedzinie sieci kolejowej, mog(cid:239)a
odby(cid:202) si(cid:218) nast(cid:218)puj(cid:200)ca rozmowa3:
Ty: Czy mo(cid:285)esz poda(cid:202) mi przyk(cid:239)ad pasa(cid:285)era podró(cid:285)uj(cid:200)cego pomi(cid:218)dzy dwoma
stacjami?
Jerzy: Pewnie. Na przyk(cid:239)ad ze stacji Parramatta do Town Hall.
Ty: Jak mog(cid:239)aby wygl(cid:200)da(cid:202) taka trasa?
Jerzy: Pasa(cid:285)er musia(cid:239)by skorzysta(cid:202) z linii Western. To bardzo cz(cid:218)sto u(cid:285)ywana
linia. Na godzin(cid:218) kursuje na niej od 8 do 16 poci(cid:200)gów, w zale(cid:285)no(cid:258)ci od pory
dnia. Po prostu trzeba zaproponowa(cid:202) nast(cid:218)pny planowy odjazd na tej linii.
Ty: Czy mo(cid:285)esz poda(cid:202) mi przyk(cid:239)ad podró(cid:285)y, w której pasa(cid:285)er ma do wyboru
wi(cid:218)cej ni(cid:285) jedn(cid:200) lini(cid:218)?
Jerzy: Tak, pasa(cid:285)er podró(cid:285)uj(cid:200)cy ze stacji Epping do Central mo(cid:285)e wybra(cid:202) lini(cid:218)
Epping lub Northern. Czas podró(cid:285)y waha si(cid:218) od oko(cid:239)o 27 minut do oko(cid:239)o 43
minut, a poci(cid:200)gi na tych liniach zwykle przyje(cid:285)d(cid:285)aj(cid:200) co kilka minut, wi(cid:218)c musimy
przekaza(cid:202) pasa(cid:285)erom wystarczaj(cid:200)co du(cid:285)o informacji na temat godzin odjazdów
i przyjazdów poci(cid:200)gów je(cid:285)d(cid:285)(cid:200)cych na obu tych liniach.
Nawet w tym prostym przyk(cid:239)adzie wida(cid:202), (cid:285)e istniej(cid:200) pewne subtelno(cid:258)ci. Propozycja
trasy nie zawsze sprowadza si(cid:218) do prostej informacji na temat godziny odjazdu nast(cid:218)p-
nego poci(cid:200)gu. Trzeba przekaza(cid:202) pasa(cid:285)erowi szczegó(cid:239)owe informacje na temat godzin
odjazdów i przyjazdów wszystkich zaplanowanych nast(cid:218)pnych poci(cid:200)gów.
3 Aby (cid:258)ledzi(cid:202) przytaczane przyk(cid:239)ady, mo(cid:285)na odnie(cid:258)(cid:202) si(cid:218) do mapy zaprezentowanej na rysunku 2.1.
Poleć książkęKup książkę64
ROZDZIA(cid:224) 2. BDD z lotu ptaka
2.4. Implementacja — budowanie i dostarczanie
cech funkcjonalnych
Po zidentyfikowaniu cech, których aplikacja potrzebuje, nale(cid:285)y je zbudowa(cid:202). W tym pod-
rozdziale przyjrzymy si(cid:218) podstawowemu cyklowi (cid:285)ycia BDD.
Dowiemy si(cid:218), w jaki sposób na podstawie przyk(cid:239)adów skoncentrowanych wokó(cid:239)
potrzeb biznesowych, które omawiali(cid:258)my w poprzednim podrozdziale, mo(cid:285)na stworzy(cid:202)
wykonywalne specyfikacje. Poka(cid:285)emy te(cid:285), jak mo(cid:285)na zautomatyzowa(cid:202) te specyfikacje
oraz w jaki sposób prowadzi to do odkrywania kodu, który trzeba napisa(cid:202). Poka(cid:285)emy
te(cid:285), (cid:285)e te specyfikacje wykonywalne mog(cid:200) by(cid:202) doskona(cid:239)ym narz(cid:218)dziem do tworzenia
raportów i tworzenia dynamicznej dokumentacji.
2.4.1. Od przyk(cid:225)adów do kryteriów akceptacji
Przyk(cid:239)ady (takie jak podró(cid:285)e, które opisa(cid:239) Jerzy) mog(cid:200) by(cid:202) wykorzystane jako podstawa
kryteriów akceptacji. W skrócie kryteria akceptacji s(cid:200) efektem, który zadowoli zaintere-
sowane strony (i przedstawicieli kontroli jako(cid:258)ci) i pozwoli im stwierdzi(cid:202), (cid:285)e aplikacja
robi to, co powinna robi(cid:202).
Rozmowy takie jak ta z Jerzym (w punkcie 2.3.3) to (cid:258)wietny sposób budowania zro-
zumienia przestrzeni problemu. Je(cid:258)li jednak u(cid:285)yjemy nieco bardziej uporz(cid:200)dkowanego
stylu, mo(cid:285)emy uzyska(cid:202) o wiele wi(cid:218)cej. W BDD do wyra(cid:285)ania przyk(cid:239)adów cz(cid:218)sto stosuje
si(cid:218) zapis w takiej oto formie4:
Zak(cid:273)adaj(cid:230)c kontekst
Gdy co(cid:295) si(cid:250) wydarzy
Wtedy oczekujemy jakiego(cid:295) efektu
Ten format pozwala my(cid:258)le(cid:202) w kategoriach sposobu interakcji u(cid:285)ytkowników z systemem
oraz oczekiwanych wyników. Jak dowiemy si(cid:218) w nast(cid:218)pnym podrozdziale, format ten
jest równie(cid:285) (cid:239)atwy do konwersji na posta(cid:202) automatycznych testów akceptacyjnych za
pomoc(cid:200) takich narz(cid:218)dzi, jak Cucumber i JBehave. Ale ze wzgl(cid:218)du na ewentualn(cid:200) pó(cid:283)-
niejsz(cid:200) mo(cid:285)liwo(cid:258)(cid:202) zautomatyzowania tych testów, ich format jest troch(cid:218) mniej elastyczny.
Jak si(cid:218) przekonamy, s(cid:239)owa Zak(cid:273)adaj(cid:230)c (ang. Given), Gdy (ang. When) i Wtedy (ang. Then) maj(cid:200)
dla tych narz(cid:218)dzi szczególne znaczenie, wi(cid:218)c najlepiej traktowa(cid:202) je jako specjalne s(cid:239)owa
kluczowe.
U(cid:285)ywaj(cid:200)c tej notacji, mo(cid:285)emy wyrazi(cid:202) przytoczone wcze(cid:258)niej wymaganie w nast(cid:218)-
puj(cid:200)cy sposób:
Jaki jest kontekst lub t(cid:225)o tego przyk(cid:225)adu?
Zak(cid:273)adaj(cid:230)c poci(cid:230)gi linii Western odje(cid:318)d(cid:318)aj(cid:230) ze stacji Parramatta o 7:58, 8:02, 8:08, 8:11
Gdy chc(cid:250) podró(cid:318)owa(cid:232) z Parramatta do Town Hall o 8:00
Wtedy powinienem uzyska(cid:232) informacj(cid:250), (cid:318)e nale(cid:318)y wsi(cid:230)(cid:295)(cid:232) w poci(cid:230)g o 8:02
Jak(cid:261) akcj(cid:266) opisujemy?
Jaki jest oczekiwany wynik?
4 Sk(cid:239)adnia zaprezentowana w tym przyk(cid:239)adzie cz(cid:218)sto jest okre(cid:258)lana jako format Gherkin, ale nie jest to
precyzyjne — Gherkin to sk(cid:239)adnia u(cid:285)ywana w aplikacji Cucumber i powi(cid:200)zanych z ni(cid:200) narz(cid:218)dziach,
natomiast w tych przyk(cid:239)adach wykorzystano JBehave. Dok(cid:239)adniej zagadnienie to zostanie opisane
w rozdziale 5.
Poleć książkęKup książkę2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych
65
Gdy rozmawia(cid:239)e(cid:258) z Jerzym, powiedzia(cid:239) Ci, (cid:285)e poci(cid:200)gi kursuj(cid:200) na linii w dwóch kierun-
kach, zatem sekcja
jest niekompletna — trzeba tak(cid:285)e poda(cid:202) stacj(cid:218) pocz(cid:200)tkow(cid:200) i kie-
runek. Drugi wariant jest taki, (cid:285)e kierunek mo(cid:285)na wywnioskowa(cid:202) na podstawie stacji
docelowej. Powy(cid:285)szy scenariusz mo(cid:285)na u(cid:258)ci(cid:258)li(cid:202) w nast(cid:218)puj(cid:200)cy sposób:
Zak(cid:273)adaj(cid:230)c poci(cid:230)gi linii Western z Emu Plains odje(cid:318)d(cid:318)aj(cid:230) ze stacji Parramatta
do Town Hall o 7:58, 8:00, 8:02, 8:11
Gdy chc(cid:250) podró(cid:318)owa(cid:232) z Parramatta do Town Hall o 8:00
Wtedy powinienem uzyska(cid:232) informacj(cid:250), (cid:318)e nale(cid:318)y wsi(cid:230)(cid:295)(cid:232) w poci(cid:230)g o 8:02
Zawiera zarówno nazw(cid:266) linii, jak i kierunek
Jednak podczas omawiania tego przyk(cid:239)adu zdajemy sobie spraw(cid:218), (cid:285)e mamy tylko dwie
minuty na zakup biletu i przej(cid:258)cie na odpowiedni peron. Naprawd(cid:218) trzeba przekaza(cid:202)
informacj(cid:218) o kilku nast(cid:218)pnych poci(cid:200)gach:
Zak(cid:273)adaj(cid:230)c poci(cid:230)gi linii Western z Emu Plains odje(cid:318)d(cid:318)aj(cid:230) ze stacji Parramatta
do Town Hall o 7:58, 8:00, 8:02, 8:11, 8:14, 8:21
Gdy chc(cid:250) podró(cid:318)owa(cid:232) z Parramatta do Town Hall o 8:00
Wtedy powinienem uzyska(cid:232) informacj(cid:250) o poci(cid:230)gach o: 8:02, 8:11, 8:14
Teraz oczekujemy trzech wyników
Podano
sze(cid:286)(cid:252) godzin
odjazdów
poci(cid:261)gów,
tak aby
przyk(cid:225)ad
sta(cid:225) si(cid:266)
bardziej
reprezen-
tatywny
Zanim rozwiniemy ten przyk(cid:239)ad lub przejdziemy do bardziej z(cid:239)o(cid:285)onych wymaga(cid:241), spró-
bujemy pokaza(cid:202), jak mo(cid:285)na przekszta(cid:239)ci(cid:202) te kryteria akceptacji na wykonywalne spe-
cyfikacje za pomoc(cid:200) narz(cid:218)dzi JBehave, Maven i Git.
2.4.2. Konfigurowanie narz(cid:266)dzi Maven i Git
Istnieje wiele specjalistycznych narz(cid:218)dzi BDD, które mo(cid:285)na wykorzysta(cid:202) w celu auto-
matyzacji kryteriów akceptacji. Do popularnych programów s(cid:239)u(cid:285)(cid:200)cych do tego celu
nale(cid:285)(cid:200) narz(cid:218)dzia JBehave, Cucumber, SpecFlow i Behat. Chocia(cid:285) nie jest to niezb(cid:218)dne,
to za pomoc(cid:200) tych narz(cid:218)dzi (cid:239)atwiej wyrazi(cid:202) zautomatyzowane testy w strukturalnej for-
mie podobnej do notacji „Zak(cid:239)adaj(cid:200)c... Gdy... Wtedy...”, zaprezentowanej w poprzednim
podrozdziale. Stosowanie tej notacji u(cid:239)atwia w(cid:239)a(cid:258)cicielom produktu i testerom zrozu-
mienie i zidentyfikowanie zautomatyzowanych kryteriów akceptacji. To z kolei pomaga
zwi(cid:218)kszy(cid:202) zaufanie do zautomatyzowanych testów i w ogóle do podej(cid:258)cia automatycz-
nego testowania akceptacyjnego.
W dalszej cz(cid:218)(cid:258)ci tej ksi(cid:200)(cid:285)ki b(cid:218)d(cid:218) prezentowa(cid:239) przyk(cid:239)ady, pos(cid:239)uguj(cid:200)c si(cid:218) kilkoma
ró(cid:285)nymi narz(cid:218)dziami BDD. W tym rozdziale b(cid:218)d(cid:218) u(cid:285)ywa(cid:239) przyk(cid:239)adów napisanych
z wykorzystaniem JBehave i j(cid:218)zyka Java5, a projekt zostanie zbudowany i uruchomiony
za pomoc(cid:200) narz(cid:218)dzia Maven6. Raporty z testów b(cid:218)d(cid:200) generowane z wykorzystaniem
Thucydides7 — biblioteki open source, która u(cid:239)atwia organizowanie i tworzenie raportów
z wyników testów BDD.
5 Je(cid:258)li czytelnik nie programuje w Javie, nie ma powodu do obaw. Przyk(cid:239)ady kodu zosta(cid:239)y napisane
w taki sposób, aby by(cid:239)y czytelne dla ka(cid:285)dego, kto ma podstawow(cid:200) wiedz(cid:218) na temat programowania.
Narz(cid:218)dzia BDD dla (cid:258)rodowisk .NET, Ruby i Python zostan(cid:200) omówione w rozdziale 5. i dalszych.
6 Maven (http://maven.apache.org/) jest powszechnie u(cid:285)ywanym narz(cid:218)dziem do budowania aplikacji
w Javie.
7 Wi(cid:218)cej informacji na temat biblioteki Thucydides mo(cid:285)na znale(cid:283)(cid:202) w witrynie internetowej tej
biblioteki (http://thucydides.info).
Poleć książkęKup książkę66
ROZDZIA(cid:224) 2. BDD z lotu ptaka
Kod (cid:283)ród(cid:239)owy dla tego rozdzia(cid:239)u jest dost(cid:218)pny w repozytorium GitHub8 oraz
w witrynie internetowej wydawnictwa Helion. Aby móc (cid:258)ledzi(cid:202) przyk(cid:239)ad, nale(cid:285)y skon-
figurowa(cid:202) (cid:258)rodowisko programistyczne z zainstalowanym nast(cid:218)puj(cid:200)cym oprogra-
mowaniem:
(cid:81) Java JDK (przyk(cid:239)adowy kod tworzono w (cid:258)rodowisku Java 1.7.0, ale powinien
bezproblemowo dzia(cid:239)a(cid:202) w (cid:258)rodowisku JDK 1.6.0).
(cid:81) Maven 3.0.x.
(cid:81) Git.
Serwis GitHub umo(cid:285)liwia dost(cid:218)p do repozytorium na ró(cid:285)ne sposoby. Je(cid:258)li zainstalowali-
(cid:258)my aplikacj(cid:218) Git i mamy skonfigurowane konto w witrynie GitHub z dost(cid:218)pem SSH9,
mo(cid:285)emy utworzy(cid:202) klon repozytorium z przyk(cid:239)adowym kodem w nast(cid:218)puj(cid:200)cy sposób:
$ git clone git@github.com:bdd-in-action/chapter-2.git
Je(cid:258)li nie ustawili(cid:258)my i nie skonfigurowali(cid:258)my kluczy SSH dla serwisu GitHub, mo(cid:285)emy
równie(cid:285) u(cid:285)y(cid:202) nast(cid:218)puj(cid:200)cego polecenia (Git poprosi o podanie nazwy u(cid:285)ytkownika
i has(cid:239)a):
$ git clone https://github.com/bdd-in-action/chapter-2.git10
Po sklonowaniu projektu warto uruchomi(cid:202) polecenie mvn verify w katalogu projektu,
aby aplikacja Maven mog(cid:239)a pobra(cid:202) zale(cid:285)no(cid:258)ci potrzebne do jej dzia(cid:239)ania oraz do uru-
chomienia projektu. Operacj(cid:218) t(cid:218) trzeba przeprowadzi(cid:202) tylko raz, ale mo(cid:285)e ona troch(cid:218)
potrwa(cid:202). Uruchom nast(cid:218)puj(cid:200)ce polecenia:
$ cd chapter-2
$ cd train-timetables
$ mvn verify
Je(cid:258)li chcesz kodowa(cid:202) ka(cid:285)dy krok samodzielnie, przejd(cid:283) do katalogu train-timetables
i prze(cid:239)(cid:200)cz si(cid:218) na ga(cid:239)(cid:200)(cid:283) start:
$ git checkout start
Gdy to zrobisz, uzyskasz prosty szkielet projektu z prawid(cid:239)owo skonfigurowanym skryp-
tem kompilacji programu Maven (plik pom.xml) oraz struktur(cid:218) katalogów, z której
mo(cid:285)esz skorzysta(cid:202). Je(cid:258)li w dowolnym momencie chcesz przyjrze(cid:202) si(cid:218) przyk(cid:239)adowemu
rozwi(cid:200)zaniu, uruchom nast(cid:218)puj(cid:200)ce polecenie:
$ git checkout master
8 Kod (cid:283)ród(cid:239)owy przyk(cid:239)adów z tego rozdzia(cid:239)u mo(cid:285)na pobra(cid:202) pod adresem https://github.com/bdd-in-
action/chapter-2.
9 Dobry przewodnik dotycz(cid:200)cy instalacji narz(cid:218)dzia Git dla ró(cid:285)nych systemów operacyjnych mo(cid:285)na
znale(cid:283)(cid:202) w pomocy serwisu GitHub (https://help.github.com/articles/set-up-git).
10Podana (cid:258)cie(cid:285)ka dost(cid:218)pu do repozytorium GitHub oraz wszystkie komendy Git dotycz(cid:200) przyk(cid:239)a-
dowych kodów z oryginalnej wersji ksi(cid:200)(cid:285)ki. Polsk(cid:200) wersj(cid:218) nale(cid:285)y pobra(cid:202) z serwisu FTP wydaw-
nictwa Helion pod adresem ftp://ftp.helion.pl/przyklady/bdddzi.zip. Dalszy opis przyk(cid:239)adów dotyczy
polskiej wersji j(cid:218)zykowej — przyp. t(cid:239)um.
Poleć książkęKup książkę2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych
67
Pocz(cid:200)tkow(cid:200) struktur(cid:218) projektu pokazano na rysunku 2.2. Jest ona zgodna ze standar-
dowymi konwencjami programu Maven. Kod aplikacji b(cid:218)dzie zapisany w katalogu
src/main/java, natomiast kod testu w katalogu src/test/java. Historyjki JBehave trafi(cid:200) do
katalogu src/test/resources/stories. AcceptanceTestSuite jest prost(cid:200) klas(cid:200) uruchamiania
testów bazuj(cid:200)c(cid:200) na frameworku JUnit, która uruchomi historyjki JBehave wewn(cid:200)trz
katalogu src/test/resources i w katalogach podrz(cid:218)dnych.
Rysunek 2.2. Pocz(cid:261)tkowa struktura projektu
2.4.3. Specyfikacje wykonywalne
— automatyzacja kryteriów akceptacji
Wyra(cid:285)anie wymaga(cid:241) w formie strukturalnych przyk(cid:239)adów daje wiele korzy(cid:258)ci. Przyk(cid:239)ady
stanowi(cid:200) doskona(cid:239)y punkt wyj(cid:258)cia do rozmów o potrzebach biznesowych i oczekiwa-
niach. W porównaniu z bardziej abstrakcyjnymi specyfikacjami pozwalaj(cid:200) lepiej wyeli-
minowa(cid:202) nieporozumienia i nieprawid(cid:239)owe za(cid:239)o(cid:285)enia. Inn(cid:200) wa(cid:285)n(cid:200) korzy(cid:258)ci(cid:200) ze stoso-
wania tej metody jest to, (cid:285)e pozwala ona na (cid:239)atwiejsze zautomatyzowanie wymaga(cid:241)
w formie testów akceptacyjnych.
Po skonfigurowaniu (cid:258)rodowiska programistycznego nadszed(cid:239) czas, aby zautomaty-
zowa(cid:202) przyk(cid:239)ad, który omówili(cid:258)my w poprzednich podrozdzia(cid:239)ach. JBehave, podobnie
jak wiele narz(cid:218)dzi BDD, wykorzystuje specjalny j(cid:218)zyk do reprezentowania specyfikacji
wykonywalnych w strukturalnym, ale nadal bardzo czytelnym formacie. W JBehave
scenariusz mo(cid:285)na wyrazi(cid:202) w sposób zaprezentowany na listingu 2.1.
Poleć książkęKup książkę68
ROZDZIA(cid:224) 2. BDD z lotu ptaka
Listing 2.1. Kryteria akceptacji wyra(cid:298)one w JBehave
Dowiedz si(cid:250), o której godzinie odje(cid:318)d(cid:318)aj(cid:230) nast(cid:250)pne poci(cid:230)gi do stacji docelowej
Opis historyjki w dowolnej formie
Tytu(cid:225) historyjki
Narracja:
W celu bardziej efektywnego planowania podró(cid:318)y
Jako podró(cid:318)ny
Chc(cid:250) si(cid:250) dowiedzie(cid:232), jakie nast(cid:250)pne poci(cid:230)gi odje(cid:318)d(cid:318)aj(cid:230) do mojej stacji docelowej
Scenariusz
Scenariusz: Znajd(cid:316) optymaln(cid:230) tras(cid:250) pomi(cid:250)dzy stacjami na tej samej linii.
Zak(cid:273)adaj(cid:230)c poci(cid:230)gi linii Western z Emu Plains odje(cid:318)d(cid:318)aj(cid:230) ze stacji Parramatta
do Town Hall o 7:58, 8:00, 8:02, 8:11, 8:14, 8:21
Testowane dzia(cid:225)anie
Gdy chc(cid:250) podró(cid:318)owa(cid:232) z Parramatta do Town Hall o 8:00
Wtedy powinienem uzyska(cid:232) informacj(cid:250) o poci(cid:230)gach o: 8:02, 8:11, 8:14
Warunki
wst(cid:266)pne
Oczekiwany rezultat
Powy(cid:285)szy opis zawiera niewiele wi(cid:218)cej w porównaniu ze strukturaln(cid:200) wersj(cid:200) przyk(cid:239)adu,
. S(cid:239)owo kluczowe
który omawiali(cid:258)my wcze(cid:258)niej. Zaczynamy od opisu historyjki
Scenariusz (ang. Scenario) oznacza pocz(cid:200)tek ka(cid:285)dego nowego scenariusza. S(cid:239)owa
kluczowe Zak(cid:273)adaj(cid:230)c (ang. Given)
wprowa-
dzaj(cid:200) poszczególne cz(cid:218)(cid:258)ci ka(cid:285)dego scenariusza.
i Wtedy (ang. Then)
W JBehave scenariusze s(cid:200) pogrupowane wed(cid:239)ug historyjek i zapisane w pliku z roz-
szerzeniem .story11. Jak mo(cid:285)na zobaczy(cid:202) na rysunku 2.3, plik zawieraj(cid:200)cy definicj(cid:218) tej
historyjki nosi nazw(cid:218) znajdz_odjazdy_nastepnych_pociagow.story.
i
, Gdy (ang. When)
Rysunek 2.3. Pliki historyjek JBehave s(cid:261) zorganizowane w postaci katalogów
11Pod tym wzgl(cid:218)dem JBehave nieco ró(cid:285)ni si(cid:218) od systemu Cucumber i narz(cid:218)dzi bazuj(cid:200)cych na systemie
Cucumber, które wykorzystuj(cid:200) pliki .feature. Do tej ró(cid:285)nicy oraz tego, co z niej wynika, powrócimy
w rozdziale 5.
Poleć książkęKup książkę2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych
69
Wszystkie pliki .story mo(cid:285)na umie(cid:258)ci(cid:202) bezpo(cid:258)rednio w katalogu stories. To jednak staje
si(cid:218) niewygodne w przypadku, gdy mamy du(cid:285)(cid:200) liczb(cid:218) plików historyjek. Zamiast tego
najlepiej pogrupowa(cid:202) historyjki w wysokopoziomowe grupy funkcjonalne. Na przyk(cid:239)ad
w miar(cid:218) rozwoju tego projektu mo(cid:285)e powsta(cid:202) nast(cid:218)puj(cid:200)ca struktura katalogów:
trasy (obliczenia tras i informacje o rozk(cid:239)adzie jazdy);
(cid:81)
(cid:81) podró(cid:285)ni (indywidualne dane dotycz(cid:200)ce podró(cid:285)y dla pasa(cid:285)erów);
(cid:81) powiadomienia (powiadomienia o opó(cid:283)nieniach dla pasa(cid:285)erów).
W celu generowania dokumentacji w ka(cid:285)dym z tych katalogów mo(cid:285)na równie(cid:285) umie-
(cid:258)ci(cid:202) plik tekstowy o nazwie narrative.txt12. Zawiera on nazw(cid:218) grupy funkcji oraz krótki
opis tego, co ona obejmuje. Na przyk(cid:239)ad plik narrative.txt dla katalogu trasy mo(cid:285)e wygl(cid:200)-
da(cid:202) tak, jak na poni(cid:285)szym listingu.
Listing 2.2. Plik narrative.txt opisuje wysokopoziomow(cid:261) funkcjonalno(cid:286)(cid:252)
Trasy i rozk(cid:273)ady jazdy
Informacje w czasie rzeczywistym o rozk(cid:273)adach jazdy i trasach
Krótki tytu(cid:225)
Krótki, dowolny opis tej wysokopoziomowej funkcjonalno(cid:286)ci
Mamy teraz specyfikacj(cid:218) wykonywaln(cid:200). Cho(cid:202) nie ma jeszcze kodu obs(cid:239)uguj(cid:200)cego ten
scenariusz, narz(cid:218)dzie JBehave nadal mo(cid:285)e j(cid:200) uruchomi(cid:202). Aby to sprawdzi(cid:202), wystarczy
przej(cid:258)(cid:202) do katalogu train-timetables i uruchomi(cid:202) poni(cid:285)sze polecenie:
$ mvn verify
Spowoduje to wygenerowanie zbioru raportów w katalogu target/site/thucydides13.
Je(cid:258)li otworzysz plik index.html w tym katalogu i klikniesz jedyny test w tabeli Test u do(cid:239)u
ekranu, powiniene(cid:258) zobaczy(cid:202) ekran podobny do pokazanego na rysunku 2.4.
W tym momencie stworzony scenariusz przesta(cid:239) by(cid:202) prostym dokumentem teksto-
wym. Teraz to jest specyfikacja wykonywalna. Mo(cid:285)e by(cid:202) uruchomiona w ramach
procesu automatycznej kompilacji w celu stwierdzenia, czy okre(cid:258)lona funkcja zosta(cid:239)a
zaimplementowana, czy nie. Gdy takie testy s(cid:200) wykonywane po raz pierwszy, s(cid:200) ozna-
czane flag(cid:200) PENDING, co w kategoriach BDD oznacza, (cid:285)e test zosta(cid:239) zautomatyzowany,
ale kod, który implementuje testowan(cid:200) funkcj(cid:218), nie zosta(cid:239) jeszcze napisany. Je(cid:258)li funkcje
zostan(cid:200) zaimplementowane, a ich testy akceptacyjne zako(cid:241)cz(cid:200) si(cid:218) sukcesem, s(cid:200) ozna-
czone s(cid:239)owem PASSED, co oznacza, (cid:285)e zako(cid:241)czyli(cid:258)my prac(cid:218) w tym obszarze.
Dynamiczna dokumentacja jest jednak czym(cid:258) wi(cid:218)cej ni(cid:285) tylko raportem z testów.
Powinna ona równie(cid:285) informowa(cid:202) o stanie wszystkich wyspecyfikowanych wymaga(cid:241),
nawet tych, dla których jeszcze nie napisano (cid:285)adnych testów. Daje to znacznie pe(cid:239)niej-
szy obraz projektu i produktu. Przyk(cid:239)ad raportu o tym poziomie szczegó(cid:239)owo(cid:258)ci mo(cid:285)emy
12Je(cid:258)li plik narrative.txt istnieje, jest równie(cid:285) wykorzystywany przez program Thucydides w celu
generowania dynamicznej dokumentacji, któr(cid:200) zaprezentujemy w dalszej cz(cid:218)(cid:258)ci tej ksi(cid:200)(cid:285)ki.
13Maven najpierw (cid:258)ci(cid:200)ga biblioteki, których potrzebuje — ta operacja mo(cid:285)e zaj(cid:200)(cid:202) troch(cid:218) czasu, ale
jest wykonywana tylko raz.
Poleć książkęKup książkę70
ROZDZIA(cid:224) 2. BDD z lotu ptaka
Rysunek 2.4. Historyjka JBehave wewn(cid:261)trz raportów z testów akceptacyjnych
zobaczy(cid:202), klikaj(cid:200)c zak(cid:239)adk(cid:218) Requirements w raporcie, który przed chwil(cid:200) wygenerowa-
li(cid:258)my (patrz rysunek 2.5). Na rysunku powinna si(cid:218) wy(cid:258)wietli(cid:202) lista wszystkich wysoko-
poziomowych wymaga(cid:241) wraz z informacj(cid:200) o tym, ile prac zrealizowano dla ka(cid:285)dego
z nich (na tym etapie b(cid:218)dzie to ca(cid:239)kowity brak prac).
Zanim omówimy, w jaki sposób mo(cid:285)na zautomatyzowa(cid:202) podobne scenariusze w Javie,
przyjrzyjmy si(cid:218) innemu wariantowi. Bardzo wa(cid:285)n(cid:200) funkcj(cid:200) tworzonej aplikacji jest
zdolno(cid:258)(cid:202) informowania podró(cid:285)nych o godzinie, o której dotr(cid:200) do stacji docelowej, je(cid:258)li
wyjad(cid:200) ze stacji pocz(cid:200)tkowej w okre(cid:258)lonym czasie. Jerzy poda(cid:239) kilka przyk(cid:239)adów, które
mo(cid:285)na wykorzysta(cid:202) w celu stworzenia scenariusza opisuj(cid:200)cego to wymaganie. Zapre-
zentowano je na listingu 2.3.
Listing 2.3. Szacowanie godziny przyjazdu
Informacja dla podró(cid:318)nych o czasie przybycia d
Pobierz darmowy fragment (pdf)