Tytuł oryginału: BDD in Action: Behavior-Driven Development for … · 2019-05-15 · Spis tre ci...

Tytuł oryginału: BDD in Action: Behavior-Driven Development for the whole software lifecycle

Tłumaczenie: Radosław MerykProjekt okładki: Studio Gravite / OlsztynObarek, 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 HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: 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/bdddziMoż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ść

http://helion.pl/rt/bdddzi

http://helion.pl/rf/bdddzi

http://helion.pl/ro/bdddzi

http://helion.pl

http://ebookpoint.pl/r/4CAKF

Spis tre ciS owo wst pne 11Przedmowa 15Podzi kowania 17O tej ksi ce 19

CZ I. PIERWSZE KROKI ......................................................................... 23

Rozdzia 1. Budowanie oprogramowania, które sprawia ró nic 251.1. BDD z wysoko ci 15 kilometrów 271.2. Jakie problemy próbujemy rozwi zywa ? 29

1.2.1. W a ciwe budowanie oprogramowania 301.2.2. Budowanie w a ciwego oprogramowania 321.2.3. Ograniczenia wiedzy — radzenie sobie z informacj niepewn 32

1.3. Wprowadzenie do programowania sterowanego zachowaniami 341.3.1. BDD pierwotnie zaprojektowano jako ulepszon wersj TDD 351.3.2. Techniki BDD równie sprawdzaj si jako narz dzia analizy wymaga 371.3.3. Zasady i praktyki BDD 38

1.4. Korzy ci z BDD 521.4.1. Mniejsze marnotrawstwo 521.4.2. Ni sze koszty 521.4.3. atwiejsze i bezpieczniejsze zmiany 531.4.4. Szybsze publikacje 53

1.5. Wady i potencjalne problemy zwi zane ze stosowaniem praktyk BDD 531.5.1. Stosowanie praktyk BDD wymaga du ego zaanga owania

i wspó pracy 531.5.2. Praktyki BDD sprawdzaj si najlepiej w kontek cie metodologii Agile

lub innej metodologii iteracyjnej 531.5.3. Praktyki BDD nie sprawdzaj si dobrze w projektach typu silos 541.5.4. le napisane testy mog prowadzi do wy szych kosztów utrzymania 54

1.6. Podsumowanie 54

Rozdzia 2. BDD z lotu ptaka 572.1. Wprowadzenie w tematyk aplikacji rozk adu jazdy poci gów 582.2. Okre lenie korzy ci ze stosowania proponowanej aplikacji 602.3. Analiza wymaga — odkrywanie i zrozumienie funkcji 60

2.3.1. Opisywanie funkcji 602.3.2. Podzia cech funkcjonalnych na historyjki 622.3.3. Ilustrowanie historyjek przyk adami 63

Poleć książkęKup książkę



4 Spis tre ci

2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 642.4.1. Od przyk adów do kryteriów akceptacji 642.4.2. Konfigurowanie narz dzi Maven i Git 652.4.3. Specyfikacje wykonywalne — automatyzacja kryteriów akceptacji 672.4.4. Automatyczne testy — implementacja kryteriów akceptacji 722.4.5. Testy jako dynamiczna dokumentacja 81

2.5. Utrzymanie 812.6. Podsumowanie 85

CZ II. CZEGO CHC ? DEFINIOWANIE WYMAGAZ WYKORZYSTANIEM BDD .........................................................87

Rozdzia 3. Zrozumie cele biznesowe. Wstrzykiwaniecech funkcjonalnych i zwi zane z tym techniki 89

3.1. Poznajemy firm Flying High 913.2. Wstrzykiwanie funkcji 92

3.2.1. Wyszukiwanie warto ci 933.2.2. Wstrzykiwanie cech funkcjonalnych 933.2.3. Wskazanie przyk adów 943.2.4. Podsumowanie 94

3.3. Co chcesz osi gn ? Zacznij od wizji 963.3.1. Formu a wizji 973.3.2. Korzystanie z szablonów formu y wizji 98

3.4. W jaki sposób firma skorzysta na projekcie? Identyfikowanie celów biznesowych 993.4.1. Pisanie dobrych celów biznesowych 1003.4.2. Poka mi pieni dze — cele biznesowe a przychody 1013.4.3. ci ganie ze „stosu dlaczego” — u ci lanie celów biznesowych 103

3.5. Mapowanie wp ywu — podej cie wizualne 1063.6. Kto na tym skorzysta? Identyfikowanie interesariuszy i ich potrzeb 1103.7. Co trzeba zbudowa ? Identyfikowanie zdolno ci 1123.8. Jakie cechy funkcjonalne zapewni najwi kszy wska nik ROI?

Model dopasowania do celów 1143.8.1. Cechy wyró niaj ce 1163.8.2. Cechy równowa ne 1163.8.3. Cechy partnerskie 1173.8.4. Cechy o minimalnym wp ywie 117


Rozdzia 4. Definiowanie i ilustrowanie cech funkcjonalnych 1194.1. Co to jest cecha funkcjonalna? 120

4.1.1. Cechy funkcjonalne dostarczaj zdolno ci 1224.1.2. Cechy funkcjonalne mo na podzieli na atwiejsze do zarz dzania

fragmenty 1264.1.3. Cecha funkcjonalna mo e by opisana za pomoc jednej lub kilku

historyjek u ytkowników 1284.1.4. Cecha funkcjonalna nie jest historyjk u ytkownika 131




Spis tre ci 5

4.1.5. Eposy to naprawd du e historyjki u ytkownika 1324.1.6. Nie wszystko pasuje do hierarchii 133

4.2. Ilustrowanie cech funkcjonalnych przyk adami 1344.3. Realne opcje — podejmuj zobowi zania dopiero wtedy, kiedy musisz 140

4.3.1. Opcje maj warto 1414.3.2. Opcje wygasaj 1434.3.3. Nigdy nie zobowi zuj si zbyt wcze nie, je li nie wiesz dlaczego 143

4.4. Celowe odkrywanie 1444.5. Od przyk adów do dzia aj cego oprogramowania — szerszy obraz 1454.6. Podsumowanie 146

Rozdzia 5. Od przyk adów do wykonywalnych specyfikacji 1495.1. Przekszta canie konkretnych przyk adów na wykonywalne scenariusze 1515.2. Pisanie wykonywalnych scenariuszy 154

5.2.1. Plik cech funkcjonalnych zawiera tytu i opis 1545.2.2. Opisywanie scenariuszy 1565.2.3. Struktura „Zak adaj c... Gdy... Wtedy” 1575.2.4. Uzupe niaj ce s owa kluczowe 1585.2.5. Komentarze 159

5.3. Wykorzystanie tabel w scenariuszach 1605.3.1. U ywanie tabel w pojedynczych krokach 1605.3.2. Wykorzystanie tabel przyk adów 161

5.4. Scenariusze ekspresywne — wzorce i antywzorce 1655.4.1. Pisanie ekspresywnych kroków Zak adaj c 1655.4.2. Pisanie ekspresywnych kroków Gdy 1665.4.3. Pisanie ekspresywnych kroków Wtedy 1675.4.4. Podawanie t a i kontekstu 1685.4.5. Unikanie zale no ci mi dzy scenariuszami 170

5.5. Organizowanie scenariuszy przy u yciu plików cech funkcjonalnych i tagów 1715.5.1. Scenariusze zapisuje si w plikach opisu cech funkcjonalnych 1725.5.2. Plik opisu cechy funkcjonalnej mo e zawiera jeden lub wi cej

scenariuszy 1725.5.3. Organizowanie plików opisu cech funkcjonalnych 1735.5.4. Opisywanie scenariuszy za pomoc tagów 174


Rozdzia 6. Automatyzacja scenariuszy 1796.1. Wprowadzenie do automatyzowania scenariuszy 182

6.1.1. Definicje kroków interpretuj tekst scenariuszy 1826.1.2. Zachowaj prostot metod definicji kroków 184

6.2. Implementacja definicji kroków — zasady ogólne 1866.2.1. Instalowanie narz dzi BDD 1866.2.2. Implementacja definicji kroków 1876.2.3. Przekazywanie parametrów do implementacji kroków 1876.2.4. Utrzymywanie stanu pomi dzy krokami 1886.2.5. Wykorzystywanie danych tabelarycznych z definicji kroków 1906.2.6. Implementacja scenariuszy bazuj cych na przyk adach 1916.2.7. Wyniki scenariusza 192




6 Spis tre ci

6.3. Bardziej efektywna implementacja BDD z wykorzystaniem narz dziaThucydides 193

6.4. Automatyzowanie scenariuszy w Javie z wykorzystaniem JBehave 1946.4.1. Instalowanie i konfigurowanie narz dzia JBehave 1946.4.2. Definicje kroków JBehave 1956.4.3. Wspó dzielenie danych pomi dzy krokami 1976.4.4. Przekazywanie tabel do kroków 1986.4.5. Definicje kroków dla tabel przyk adów 1996.4.6. Warianty wzorców 2006.4.7. Niepowodzenia i b dy w wynikach scenariuszy 200

6.5. Automatyzowanie scenariuszy w Javie przy u yciu narz dziaCucumber-JVM 2026.5.1. Konfiguracja i struktura projektu Cucumber-JVM 2026.5.2. Definicje kroków Cucumber-JVM 2036.5.3. Warianty wzorców 2046.5.4. Przekazywanie tabel do definicji kroków 2056.5.5. Definicje kroków dla tabel przyk adów 2066.5.6. Wspó dzielenie danych pomi dzy krokami 2066.5.7. Kroki oczekuj ce i wyniki kroków 207

6.6. Automatyzowanie scenariuszy w Pythonie z wykorzystaniem Behave 2076.6.1. Instalacja systemu Behave 2086.6.2. Struktura projektu Behave 2086.6.3. Definicje kroków Behave 2096.6.4. czenie kroków 2096.6.5. Definicje kroków z wykorzystaniem osadzonych tabel 2106.6.6. Definicje kroków dla tabel przyk adów 2106.6.7. Uruchamianie scenariuszy w Behave 210

6.7. Automatyzowanie scenariuszy w .NET z wykorzystaniem SpecFlow 2116.7.1. Konfigurowanie SpecFlow 2116.7.2. Dodawanie plików opisu cech funkcjonalnych 2116.7.3. Uruchamianie scenariuszy 2136.7.4. Definicje kroków w SpecFlow 2136.7.5. Wspó dzielenie danych pomi dzy krokami 2146.7.6. Definicje kroków z wykorzystaniem tabel przyk adów 215

6.8. Automatyzowanie scenariuszy w JavaScript z wykorzystaniem systemuCucumber-JS 2166.8.1. Konfigurowanie systemu Cucumber-JS 2166.8.2. Pisanie plików opisu funkcji w Cucumber-JS 2176.8.3. Implementowanie kroków 2186.8.4. Uruchamianie scenariuszy 219


CZ III. JAK TO ZBUDOWA ? KODOWANIE ZGODNE Z BDD ..............219

Rozdzia 7. Od wykonywalnych specyfikacji do solidnych automatycznychtestów akceptacyjnych 223

7.1. Pisanie niezawodnych testów akceptacji 2257.2. Automatyzowanie procesu konfiguracji testu 228




Spis tre ci 7

7.2.1. Inicjowanie bazy danych przed ka dym testem 2287.2.2. Inicjowanie bazy danych na pocz tku zestawu testów 2297.2.3. Korzystanie z haków inicjalizacji 2297.2.4. Konfigurowanie danych specyficznych dla scenariusza 2337.2.5. U ycie person i znanych encji 235

7.3. Oddzielenie warstwy „co” od warstwy „jak” 2377.3.1. Warstwa regu biznesowych opisuje oczekiwane rezultaty 2387.3.2. Warstwa przep ywu pracy opisuje dzia ania u ytkownika 2397.3.3. Warstwa techniczna realizuje interakcje z systemem 2417.3.4. Ile warstw? 242


Rozdzia 8. Automatyzacja kryteriów akceptacjidla warstwy interfejsu u ytkownika 245

8.1. Kiedy i jak nale y testowa interfejs u ytkownika? 2478.1.1. Zagro enie zbyt wieloma testami webowymi 2478.1.2. Testy webowe z przegl darkami w trybie headless 2488.1.3. Ile testów webowych naprawd potrzebujemy? 250

8.2. Automatyzowanie webowych kryteriów akceptacjiz wykorzystaniem programu Selenium WebDriver 2518.2.1. Pierwsze kroki z WebDriver w Javie 2528.2.2. Identyfikacja elementów strony WWW 2558.2.3. Interakcje z elementami stron WWW 2638.2.4. Praca ze stronami asynchronicznymi i testowanie aplikacji AJAX 2658.2.5. Pisanie aplikacji webowych „przyjaznych dla testów” 267

8.3. Korzystanie z obiektów stron w celu poprawy czytelno ci testów 2678.3.1. Wprowadzenie do wzorca Obiekty stron 2688.3.2. Pisanie dobrze zaprojektowanych obiektów stron 2738.3.3. Korzystanie z bibliotek rozszerzaj cych bibliotek WebDriver 279


Rozdzia 9. Automatyzacja kryteriów akceptacjidla wymaga niekorzystaj cych z UI 283

9.1. Równowaga pomi dzy testami akceptacyjnymi z wykorzystaniem UI i bez UI 2859.2. Kiedy u ywa testów akceptacji bez po rednictwa UI 2869.3. Typy automatycznych testów akceptacji niekorzystaj cych z UI 290

9.3.1. Testowanie z wykorzystaniem warstwy kontrolera 2919.3.2. Bezpo rednie testowanie logiki biznesowej 2959.3.3. Testowanie warstwy us ug 299

9.4. Definiowanie i testowanie wymaga niefunkcjonalnych 3049.5. Odkrywanie projektu 3069.6. Podsumowanie 308




8 Spis tre ci

Rozdzia 10. BDD a testy jednostkowe 30910.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 31310.1.3. Narz dzia BDD do testów jednostkowych 313

10.2. Od kryteriów akceptacji do zaimplementowanych cech funkcjonalnych 31310.2.1. BDD sprzyja stosowaniu podej cia „z zewn trz do wewn trz” 31410.2.2. Zaczynamy od wysokopoziomowego kryterium akceptacji 31610.2.3. Automatyzacja scenariuszy kryteriów akceptacji 31710.2.4. Implementacja definicji kroków 31710.2.5. Zrozumienie modelu domeny 31810.2.6. Pisanie kodu, który chcieliby my mie 31910.2.7. Wykorzystanie kodu definicji kroku do wyspecyfikowania

i zaimplementowania kodu aplikacji 31910.2.8. W jaki sposób stosowanie praktyk BDD pomog o? 324

10.3. Analiza niskopoziomowych wymaga , odkrywanie projektui implementacja bardziej z o onych funkcjonalno ci 32510.3.1. Wykorzystanie kodu definicji kroku do analizy niskopoziomowego

projektu 32610.3.2. Praca z tabelami przyk adów 32810.3.3. Odkrywanie nowych klas i us ug w miar implementowania kodu

produkcyjnego 33010.3.4. Natychmiastowa implementacja prostych klas lub metod 33110.3.5. Wykorzystanie minimalnej implementacji 33110.3.6. Wykorzystanie namiastek i makiet w celu odroczenia implementacji

bardziej z o onego kodu 33210.3.7. Rozwijanie niskopoziomowych specyfikacji technicznych 333

10.4. Narz dzia, dzi ki którym testy jednostkowe BDD staj si atwiejsze 33610.4.1. Stosowanie praktyk BDD z tradycyjnymi narz dziami testów

jednostkowych 33610.4.2. Pisanie specyfikacji, a nie testów — rodzina RSpec 33910.4.3. Pisanie bardziej ekspresywnych specyfikacji z wykorzystaniem

narz dzi Spock albo Spec2 34310.5. U ywanie wykonywalnych specyfikacji jako dynamicznej dokumentacji 345

10.5.1. U ywanie p ynnego kodowania w celu poprawy czytelno ci 34610.5.2. P ynne asercje w j zyku JavaScript 34710.5.3. P ynne asercje w j zykach statycznych 347


CZ IV. ZAAWANSOWANE ASPEKTY BDD ............................................349

Rozdzia 11. Dynamiczna dokumentacja — raportowanie a zarz dzanieprojektem 353

11.1. Dynamiczna dokumentacja — widok wysokopoziomowy 35411.2. Czy osi gn li my cel? Raporty dotycz ce gotowo ci

i pokrycia cech funkcjonalnych 356




Spis tre ci 9

11.2.1. Gotowo cech funkcjonalnych — jakie cechy s gotowedo dostarczenia 356

11.2.2. Pokrycie cechy funkcjonalnej — jakie wymagania zosta y spe nione 35711.3. Integracja z cyfrowym rejestrem projektu 36011.4. Organizowanie dynamicznej dokumentacji 362

11.4.1. Organizowanie dynamicznej dokumentacjiwed ug wysokopoziomowych wymaga 363

11.4.2. Organizowanie dynamicznej dokumentacji z wykorzystaniem tagów 36411.4.3. Dynamiczna dokumentacja do tworzenia raportów

na temat publikacji oprogramowania 36411.5. Dostarczanie dokumentacji w lu niejszej formie 36611.6. Techniczna dynamiczna dokumentacja 368

11.6.1. Testy jednostkowe jako dynamiczna dokumentacja 36911.6.2. Dynamiczna dokumentacja dla starszych aplikacji 371


Rozdzia 12. BDD w procesie budowania 37312.1. Wykonywalne specyfikacje powinny by cz ci automatycznego

procesu budowy 37412.1.1. Ka da specyfikacja powinna by samowystarczalna 37512.1.2. Wykonywalne specyfikacje powinny by przechowywane

w systemie kontroli wersji 37612.1.3. Powinna istnie mo liwo uruchomienia wykonywalnych specyfikacji

z wiersza polecenia 37712.2. Ci g a integracja przyspiesza cykl sprz enia zwrotnego 37812.3. Ci g e dostawy — ka da kompilacja jest potencjaln wersj

do opublikowania 38012.4. Strategia ci g ej integracji w celu wdra ania dynamicznej dokumentacji 383

12.4.1. Publikowanie dynamicznej dokumentacji na serwerze kompilacji 38412.4.2. Publikowanie dynamicznej dokumentacji na dedykowanym

serwerze WWW 38512.5. Szybsze zautomatyzowane kryteria akceptacji 385

12.5.1. Uruchamianie równoleg ych testów akceptacyjnychw obr bie zautomatyzowanego procesu budowy 386

12.5.2. Uruchamianie równoleg ych testów na wielu maszynach 38812.5.3. Uruchamianie równoleg ych testów webowych

z wykorzystaniem Selenium Grid 39112.6. Podsumowanie 39512.7. Ostatnie s owa 396

Skorowidz 399




10 Spis tre ci




BDD z lotu ptaka

W tym rozdziale:

Wyczerpuj cy przegl d praktyk BDD w akcji.

Odkrywanie cech funkcjonalnych i opisywanieich za pomoc historyjek i przyk adów.

Wykorzystanie wykonywalnych specyfikacjido szczegó owego opisywania cech.

Wykorzystanie niskopoziomowych praktyk BDDdo implementacji cech funkcjonalnych.

Wykorzystanie wyników testów BDD jako dynamicznejdokumentacji.

Wykorzystanie dynamicznej dokumentacji w celuwsparcia bie cego utrzymania aplikacji.

W tym rozdziale przeanalizujemy konkretny przyk ad wykorzystania praktyk BDDw rzeczywistym projekcie. Jak dowiedzieli my si z poprzedniego rozdzia u, stosowa-nie praktyk BDD wi e si z zaanga owaniem zespo u rozwojowego w czasie trwaniaca ego projektu w rozmowy z klientem, a tak e z wykorzystaniem przyk adów do budo-wania bardziej konkretnego i jednoznacznego zrozumienia realnych potrzeb firmy. Spe-cyfikacje s budowane w formie wykonywalnej. Mo na je wykorzysta do okre leniawymaga dotycz cych oprogramowania, kierowania ich implementacj oraz weryfiko-wania poprawno ci dostarczanego produktu. Mo na równie stosowa te techniki pod-czas bardziej wysokopoziomowej analizy wymaga . Ich wykorzystanie pozwala skupisi na tych mo liwo ciach i funkcjach aplikacji, które przynios rzeczywist warto dlabiznesu.




58 ROZDZIA 2. BDD z lotu ptaka

Kluczowym elementem tej praktyki jest okre lanie scenariuszy lub konkretnychprzyk adów sposobu dzia ania okre lonej funkcji lub zdefiniowanej historyjki u ytkow-nika. Scenariusze te pomagaj zweryfikowa poprawno rozumienia problemu i roz-szerzy wiedz na jego temat. S one równie doskona ym narz dziem komunikacji.Stanowi fundament kryteriów akceptacji, które mo na pó niej zintegrowa z procesemkompilacji w formie automatycznych testów akceptacyjnych. W po czeniu z automa-tycznymi testami akceptacyjnymi te przyk ady steruj procesem rozwoju. Pomagajprojektantom przygotowa projekt skutecznego i funkcjonalnego interfejsu u yt-kownika oraz wspieraj deweloperów w odkrywaniu podstawowych zachowa , któretrzeba zaimplementowa , aby dostarczy wymagane cechy funkcjonalne.

W pozosta ej cz ci tego rozdzia u przyjrzymy si praktycznemu przyk adowi zasto-sowania tego procesu. W opisie uwzgl dnimy aspekty ca ego cyklu rozwoju — od ana-lizy biznesowej a do implementacji, testowania i utrzymania kodu.

2.1. Wprowadzenie w tematyk aplikacjirozk adu jazdy poci gów

Aby zilustrowa przyk adem tematyk omawian w niniejszym rozdziale, za ó my, epracujesz dla du ej rz dowej agencji transportu publicznego. Poproszono Ci , abypokierowa niewielkim zespo em maj cym za zadanie stworzenie us ugi, która dostar-czy danych na temat rozk adu jazdy poci gów oraz w czasie rzeczywistym zapewni daneo opó nieniach, pracach nad trakcj itp. Us uga ta ma by dost pna dla ró nych apli-kacji mobilnych u ywanych przez osoby doje d aj ce do pracy. Sie kolejow , którwykorzystamy w przyk adzie, pokazano na rysunku 2.1.

W dziale w a nie wdro ono praktyki Agile i BDD, zaczynasz wi c od rozmowy z klu-czowymi interesariuszami, aby upewni si , e Ty i Twój zespó macie czytelny obrazcelów biznesowych steruj cych projektem. To pomo e zespo owi dostarczy lepsz ,bardziej ukierunkowan aplikacj .

Gdy cele biznesowe zostan zrozumiane i wyartyku owane, trzeba b dzie pracowarazem z analitykami biznesowymi i przedstawicielami biznesowymi w celu podj ciadecyzji dotycz cej cech funkcjonalnych oprogramowania, za pomoc których b dziemo na osi gn te cele. Cechy te s wymaganiami wysokiego poziomu w postaci: „zapew-nienie podró nym optymalnej trasy pomi dzy stacjami” lub „powiadamianie podró nycho opó nieniach poci gu”.

Prawdopodobnie nie uda si zrealizowa tak obszernych cech funkcjonalnych w jed-nym kawa ku, dlatego trzeba je rozbi na mniejsze jednostki, znane w ród zespo ówpraktykuj cych metodyk Agile jako historyjki. Historyjki mog obejmowa takie dzia-ania, jak „znajd optymaln tras mi dzy stacjami na tej samej linii” lub „znajd opty-

maln tras mi dzy stacjami na ró nych liniach”.Przyst puj c do implementacji historyjki, spotka e si z analitykiem biznesowym,

programist i testerem, aby opisa t historyjk za pomoc konkretnych przyk adów.Wiele z tych przyk adów zosta o wcze niej omówionych z przedstawicielami biznesu.Przyk ady te stan si kryteriami akceptacji dla historyjki. S one wyra one w formal-nym stylu BDD, który pó niej mo na zautomatyzowa :




2.1. Wprowadzenie w tematyk aplikacji rozk adu jazdy poci gów 59

Rysunek 2.1. Fragment sieci kolejowej w Sydney

Zak adaj c poci gi linii Western odje d aj z Parramatta o 7:58, 8:02, 8:08, 8:11Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj , e nale y wsi w poci g o 8:02

Wspomniane kryteria akceptacji spe niaj rol punktu wyj cia dla prac rozwojowych.Ze wzgl du na to, e do prowadzenia projektów programistycznych w Twoim dziale jestwykorzystywany j zyk Java, kryteria akceptacji b d zautomatyzowane za pomocnarz dzia Javy o nazwie JBehave, natomiast kod aplikacji b dzie napisany w Javie.

Podczas tworzenia cechy b dziemy korzysta z bardziej niskopoziomowego narz -dzia BDD do testów jednostkowych o nazwie Spock. Narz dzie to pomo e zaprojekto-wa i udokumentowa implementacj oraz sprawdzi jej poprawno .

B d równie generowane raporty z testów i tworzona dynamiczna dokumentacjana podstawie zautomatyzowanych kryteriów akceptacji. W ten sposób zilustrujemy tefunkcje, które ju zosta y wykonane, oraz zaprezentujemy sposób ich dzia ania.

Celem niniejszego rozdzia u jest zaprezentowanie koncepcji podej cia oraz zapo-znanie z niektórymi z u ywanych technologii. Nie jest nim natomiast zaprezentowaniekompletnego dzia aj cego przyk adu u ycia konkretnego stosu technologii. Zamie cimyjednak wystarczaj co du o szczegó ów technicznych do tego, by by a mo liwa analizaprzyk adu. W kolejnych rozdzia ach przyjrzymy si znacznie dok adniej ka demuz zagadnie poruszanych w tym rozdziale, a tak e wielu innym.





2.2. Okre lenie korzy cize stosowania proponowanej aplikacji

Jednym z kluczowych celów stosowania praktyk BDD jest zadbanie o to, aby wszyscyuczestnicy projektu dok adnie rozumieli, co projekt stara si zrealizowa , a tak e znalijego podstawowe cele biznesowe. To samo w sobie sprowadza si do zapewnienia zre-alizowania tych celów przez aplikacj .

Mo na to osi gn w wyniku wspó pracy z u ytkownikami i innymi interesariu-szami w celu zdefiniowania lub wyja nienia wysokopoziomowych celów biznesowychaplikacji. Cele te powinny dostarcza zwi z ej wizji tego, co potrzebujemy stworzy .Cele biznesowe dotycz dostarczania warto ci, powszechnie stosuje si wi c wyra anieich w kategoriach zwi kszonych lub bezpiecznych dochodów lub obni enia kosztów.

W tym przypadku celem aplikacji, któr budujemy, jest dostarczenie podró nymrozk adów poci gów i aktualizacji w czasie rzeczywistym. Podstawowy cel biznesowy tejaplikacji mo na wyrazi w nast puj cy sposób:Zwi kszenie przychodów ze sprzeda y biletów dzi ki u atwieniu podró y poci giemi zwi kszenie wydajno ci takiego sposobu podró owania

Zrozumienie i zdefiniowanie celów aplikacji znacznie u atwia ustalenie wzgl dnej war-to ci planowanej cechy funkcjonalnej. Na przyk ad cecha funkcjonalna, która powiada-mia podró nych o spó nieniu ich poci gu, przyczynia si do ogólnego celu, poniewadaje podró nym mo liwo odpowiedniej zmiany planów. Z drugiej strony, cecha, którapozwala podró nym ocenia poszczególne stacje kolejowe, mo e by uznana za niezbytwarto ciow .

2.3. Analiza wymaga — odkrywanie i zrozumienie funkcjiKiedy u wiadomimy sobie wysokopoziomowe cele aplikacji, mo emy zacz wspó pracz interesariuszami, aby okre li dok adnie, czego potrzebuj , eby osi gn te cele.Zazwyczaj polega to na zdefiniowaniu zestawu cech funkcjonalnych, które nale y zaim-plementowa w aplikacji w celu dostarczenia warto ci, których poszukujemy.

Dla potrzeb niniejszego rozdzia u za ó my, e uzgodnili my z zainteresowanymistronami nast puj ce kluczowe cechy funkcjonalne:

Zaproponowanie podró nym optymalnej trasy. Zapewnienie podró nym w czasie rzeczywistym informacji na temat opó nie

w formie zestawienia. Umo liwienie podró nym nagrywania swoich ulubionych podró y. Powiadamianie podró nych o opó nieniach ich poci gu.

Przyjrzyjmy si , jak mo na opisa niektóre z tych cech.

2.3.1. Opisywanie funkcji

Po uzyskaniu ogólnego poj cia o cechach funkcjonalnych, które chcemy dostarczy ,nale y opisa je bardziej szczegó owo. Istnieje wiele sposobów opisywania wymaga .




2.3. Analiza wymaga — odkrywanie i zrozumienie funkcji 61

Zespo y stosuj ce metodologi Agile zazwyczaj pisz krótki zarys wymagania w for-macie na tyle zwi z ym, aby zmie ci si na pojedynczej karcie katalogowej1. Zespo ykorzystaj ce z praktyk BDD cz sto u ywaj nast puj cego formatu:

W celu <osi gni cia celu biznesowego lub dostarczenia warto ci biznesowej>Jako <interesariusz>Chc <czego >

Kolejno w tym przypadku ma znaczenie. Podczas planowania cechy funkcjonalneji historii g ównym celem powinno by dostarczenie warto ci biznesowej. Nale y roz-pocz od okre lenia warto ci biznesowej, jak staramy si dostarczy , nast pniepodajemy, kto potrzebuje funkcji, któr proponujemy , i na koniec wymieniamy cechfunkcjonaln , która b dzie wspomaga osi gni cie tego celu .

Taki sposób opisywania pomaga uzyska pewno , e ka da cecha funkcjonalnaaktywnie przyczynia si do osi gni cia celu biznesowego, a to zmniejsza ryzyko wyst -pienia niekontrolowanego rozrastania si zakresu projektu (ang. scope creep). Taki opisspe nia równie rol wygodnego przypomnienia powodów, dla których implementujemyt cech . Na przyk ad mo na powiedzie co takiego:

W celu bardziej efektywnego planowania podró yJako podró nyChc zna optymaln tras pomi dzy dwoma stacjami

To nie jest jedyna mo liwo . Wiele zespo ów u ywa szablonów popularnych wewcze niejszych podej ciach Agile:

Jako <interesariusz>Chc <czego >Tak, abym <móg osi gn pewien cel biznesowy>

Ta odmiana opisu ma pomóc deweloperom zrozumie kontekst wymagania w katego-riach tego, kto b dzie u ywa cechy funkcjonalnej i czego od niej oczekuje. Interesa-riusz odnosi si do osoby u ywaj cej cechy funkcjonalnej lub osoby zaintereso-wanej wynikiem jej dzia ania. Cel biznesowy identyfikuje powód, dla którego tacecha jest potrzebna, i warto , jak ma ona zapewni . Odpowiednikiem opisu cechyfunkcjonalnej podanego wcze niej mo e by nast puj cy opis:Jako podró nyChc zna najlepszy sposób podró owania pomi dzy dwoma stacjamiTak, abym móg szybko dotrze do celu podró y

Oba te formaty s wygodnymi konwencjami, ale nie istnieje obowi zek wybrania jed-nego lub drugiego formatu, pod warunkiem e pami tamy o jasnym wyra eniu korzy ci

1 Te karty katalogowe mog by pó niej u yte do zaplanowania i wizualizacji post pów.2 Taki format zosta pierwotnie zaproponowany przez Chrisa Mattsa w kontek cie wstrzykiwania

funkcjonalno ci — zagadnienia, któremu przyjrzymy si w nast pnym rozdziale.

Kto tego potrzebuje?

Jakie cele biznesowe staramy si osi gn ?

Co trzeba zrobi , aby umo liwi osi gni cie tego celu?

Jak warto biznesowstaramy si dostarczy ?

Kto jest zainteresowany tak cech ?

Co cecha funkcjonalna b dzie robi ?

Kto skorzysta z tej cechy; kto jej chce?

Co cecha funkcjonalna robi?

Jakie warto ci biznesoweinteresariusze uzyskajprzez t cech funkcjonaln ?





biznesowych. Na przyk ad, niektórzy do wiadczeni praktycy ch tnie korzystaj z notacji„W celu... Jako... Chc ” do opisania takich cech wysokopoziomowych, w których k a-dziemy nacisk na warto ci biznesowe, jakie system powinien dostarczy , natomiast dookre lenia bardziej szczegó owych historyjek u ytkowników w ramach cechy funkcjo-nalnej, gdy historie dotycz wyra nie dostarczania warto ci dla poszczególnych u yt-kowników w ramach tej cechy, stosuj konwencj „Jako... Chc ... Tak, aby”.

2.3.2. Podzia cech funkcjonalnych na historyjki

Cecha funkcjonalna czasami jest sformu owana wystarczaj co szczegó owo, aby mo naby o przyst pi do jej realizacji od razu, ale cz sto trzeba j podzieli na mniejsze frag-menty. W projektach Agile wi ksze cechy funkcjonalne cz sto s dzielone na histo-ryjki u ytkownika. Ka da historyjka dotyczy odr bnego aspektu problemu i jest wystar-czaj co zwi z a, aby mo na j by o dostarczy w pojedynczej iteracji.

Na przyk ad funkcja „zaproponowanie podró nym optymalnej trasy” mo e by zbytdu a, aby stworzy j za jednym razem (z punktu widzenia deweloperów znalezienietrasy obejmuj ce czenie kilku poci gów to skomplikowana operacja). Ponadto, bymo e przed zbudowaniem ca ej cechy funkcjonalnej chcieliby my uzyska jakie opi-nie na temat projektu interfejsu u ytkownika. T cech mo na podzieli na mniejszehistoryjki, na przyk ad:

Znajd optymaln tras pomi dzy stacjami na tej samej linii. Dowiedz si , o której godzinie odje d aj nast pne poci gi do stacji docelowej. Znajd optymaln tras pomi dzy stacjami na ró nych liniach.

Mo na opisa te historyjki troch bardziej szczegó owo, stosuj c ten sam format, któ-rego u ywali my w odniesieniu do funkcji:Historyjka: Znajd optymaln tras pomi dzy stacjami na tej samej linii.W celu dotarcia do miejsca docelowego na czasJako podró nyChc si dowiedzie , do jakiego poci gu powinienem wsi

Historyjka: Dowiedz si , o której godzinie odje d aj nast pne poci gi do stacji docelowejW celu bardziej efektywnego planowania podró yJako podró nyChc si dowiedzie , jakie nast pne poci gi odje d aj do mojej stacji docelowej

Historyjka: Znajd optymaln tras pomi dzy stacjami na ró nych liniachW celu dotarcia do miejsca docelowego na czasJako podró nyChc si dowiedzie , do jakiego poci gu powinienem wsiOraz uzyska szczegó owe informacje na temat potrzebnych po cze

Zwró my uwag , e pokazana lista historyjek w adnym razie nie jest sztywnym zbio-rem specyfikacji, pod którym powinni si podpisa u ytkownicy i deweloperzy. Defi-niowanie historyjek jest dynamicznym, iteracyjnym procesem maj cym na celu u atwie-nie komunikacji i zapewnienie wspólnego zrozumienia przestrzeni problemu. Podczasimplementowania poszczególnych historyjek mo emy uzyska opinie od interesariuszy.Na podstawie tych opinii mo na u ci li inne historyjki, usun niektóre z nich b d




2.3. Analiza wymaga — odkrywanie i zrozumienie funkcji 63

doda nowe, które w inny sposób mog przyczyni si do osi gni cia celów bizneso-wych. Odkrywanie funkcji i tworzenie historyjek jest ci g ym procesem poznawaniaprzestrzeni problemu.

2.3.3. Ilustrowanie historyjek przyk adami

Po zidentyfikowaniu pewnego zbioru warto ciowych cech funkcjonalnych i historyjekmo emy przyst pi do analizowania ich w sposób bardziej szczegó owy. Bardzo skutecz-nym sposobem, aby to zrobi , jest poproszenie u ytkowników i innych interesariuszyo podanie konkretnych przyk adów.

Kiedy u ytkownik pyta nas o cech funkcjonaln , cz sto od razu zaczynamy budo-wa koncepcyjny model problemu, który nale y rozwi za . Je li b dziemy post powaw ten sposób, nasze zrozumienie problemu mo e by atwo zak ócone przez niejawnei niewypowiedziane za o enia. To mo e doprowadzi do stworzenia niedok adnegomodelu mentalnego, a nast pnie do b dnej implementacji. Poproszenie interesariuszyo konkretne przyk ady tego, co maj na my li, to wietny sposób sprawdzenia i potwier-dzenia w a ciwego zrozumienia problemu.

Na przyk ad pomi dzy Tob a Jerzym, ekspertem w dziedzinie sieci kolejowej, mog aodby si nast puj ca rozmowa3:

Ty: Czy mo esz poda mi przyk ad pasa era podró uj cego pomi dzy dwomastacjami?Jerzy: Pewnie. Na przyk ad ze stacji Parramatta do Town Hall.Ty: Jak mog aby wygl da taka trasa?Jerzy: Pasa er musia by skorzysta z linii Western. To bardzo cz sto u ywanalinia. Na godzin kursuje na niej od 8 do 16 poci gów, w zale no ci od porydnia. Po prostu trzeba zaproponowa nast pny planowy odjazd na tej linii.Ty: Czy mo esz poda mi przyk ad podró y, w której pasa er ma do wyboruwi cej ni jedn lini ?Jerzy: Tak, pasa er podró uj cy ze stacji Epping do Central mo e wybra liniEpping lub Northern. Czas podró y waha si od oko o 27 minut do oko o 43minut, a poci gi na tych liniach zwykle przyje d aj co kilka minut, wi c musimyprzekaza pasa erom wystarczaj co du o informacji na temat godzin odjazdówi przyjazdów poci gów je d cych na obu tych liniach.

Nawet w tym prostym przyk adzie wida , e istniej pewne subtelno ci. Propozycjatrasy nie zawsze sprowadza si do prostej informacji na temat godziny odjazdu nast p-nego poci gu. Trzeba przekaza pasa erowi szczegó owe informacje na temat godzinodjazdów i przyjazdów wszystkich zaplanowanych nast pnych poci gów.

3 Aby ledzi przytaczane przyk ady, mo na odnie si do mapy zaprezentowanej na rysunku 2.1.





2.4. Implementacja — budowanie i dostarczaniecech funkcjonalnych

Po zidentyfikowaniu cech, których aplikacja potrzebuje, nale y je zbudowa . W tym pod-rozdziale przyjrzymy si podstawowemu cyklowi ycia BDD.

Dowiemy si , w jaki sposób na podstawie przyk adów skoncentrowanych wokópotrzeb biznesowych, które omawiali my w poprzednim podrozdziale, mo na stworzywykonywalne specyfikacje. Poka emy te , jak mo na zautomatyzowa te specyfikacjeoraz w jaki sposób prowadzi to do odkrywania kodu, który trzeba napisa . Poka emyte , e te specyfikacje wykonywalne mog by doskona ym narz dziem do tworzeniaraportów i tworzenia dynamicznej dokumentacji.

2.4.1. Od przyk adów do kryteriów akceptacji

Przyk ady (takie jak podró e, które opisa Jerzy) mog by wykorzystane jako podstawakryteriów akceptacji. W skrócie kryteria akceptacji s efektem, który zadowoli zaintere-sowane strony (i przedstawicieli kontroli jako ci) i pozwoli im stwierdzi , e aplikacjarobi to, co powinna robi .

Rozmowy takie jak ta z Jerzym (w punkcie 2.3.3) to wietny sposób budowania zro-zumienia przestrzeni problemu. Je li jednak u yjemy nieco bardziej uporz dkowanegostylu, mo emy uzyska o wiele wi cej. W BDD do wyra ania przyk adów cz sto stosujesi zapis w takiej oto formie4:Zak adaj c <kontekst>Gdy <co si wydarzy>Wtedy <oczekujemy jakiego efektu>

Ten format pozwala my le w kategoriach sposobu interakcji u ytkowników z systememoraz oczekiwanych wyników. Jak dowiemy si w nast pnym podrozdziale, format tenjest równie atwy do konwersji na posta automatycznych testów akceptacyjnych zapomoc takich narz dzi, jak Cucumber i JBehave. Ale ze wzgl du na ewentualn pó -niejsz mo liwo zautomatyzowania tych testów, ich format jest troch mniej elastyczny.Jak si przekonamy, s owa Zak adaj c (ang. Given), Gdy (ang. When) i Wtedy (ang. Then) majdla tych narz dzi szczególne znaczenie, wi c najlepiej traktowa je jako specjalne s owakluczowe.

U ywaj c tej notacji, mo emy wyrazi przytoczone wcze niej wymaganie w nast -puj cy sposób:

Zak adaj c poci gi linii Western odje d aj ze stacji Parramatta o 7:58, 8:02, 8:08, 8:11Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj , e nale y wsi w poci g o 8:02

4 Sk adnia zaprezentowana w tym przyk adzie cz sto jest okre lana jako format Gherkin, ale nie jest to

precyzyjne — Gherkin to sk adnia u ywana w aplikacji Cucumber i powi zanych z ni narz dziach,natomiast w tych przyk adach wykorzystano JBehave. Dok adniej zagadnienie to zostanie opisanew rozdziale 5.

Jaki jest kontekst lub t o tego przyk adu?

Jak akcj opisujemy?

Jaki jest oczekiwany wynik?




2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 65

Gdy rozmawia e z Jerzym, powiedzia Ci, e poci gi kursuj na linii w dwóch kierun-kach, zatem sekcja jest niekompletna — trzeba tak e poda stacj pocz tkow i kie-runek. Drugi wariant jest taki, e kierunek mo na wywnioskowa na podstawie stacjidocelowej. Powy szy scenariusz mo na u ci li w nast puj cy sposób:Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramattado Town Hall o 7:58, 8:00, 8:02, 8:11Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj , e nale y wsi w poci g o 8:02

Jednak podczas omawiania tego przyk adu zdajemy sobie spraw , e mamy tylko dwieminuty na zakup biletu i przej cie na odpowiedni peron. Naprawd trzeba przekazainformacj o kilku nast pnych poci gach:Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramattado Town Hall o 7:58, 8:00, 8:02, 8:11, 8:14, 8:21Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj o poci gach o: 8:02, 8:11, 8:14

Zanim rozwiniemy ten przyk ad lub przejdziemy do bardziej z o onych wymaga , spró-bujemy pokaza , jak mo na przekszta ci te kryteria akceptacji na wykonywalne spe-cyfikacje za pomoc narz dzi JBehave, Maven i Git.

2.4.2. Konfigurowanie narz dzi Maven i Git

Istnieje wiele specjalistycznych narz dzi BDD, które mo na wykorzysta w celu auto-matyzacji kryteriów akceptacji. Do popularnych programów s u cych do tego celunale narz dzia JBehave, Cucumber, SpecFlow i Behat. Chocia nie jest to niezb dne,to za pomoc tych narz dzi atwiej wyrazi zautomatyzowane testy w strukturalnej for-mie podobnej do notacji „Zak adaj c... Gdy... Wtedy...”, zaprezentowanej w poprzednimpodrozdziale. Stosowanie tej notacji u atwia w a cicielom produktu i testerom zrozu-mienie i zidentyfikowanie zautomatyzowanych kryteriów akceptacji. To z kolei pomagazwi kszy zaufanie do zautomatyzowanych testów i w ogóle do podej cia automatycz-nego testowania akceptacyjnego.

W dalszej cz ci tej ksi ki b d prezentowa przyk ady, pos uguj c si kilkomaró nymi narz dziami BDD. W tym rozdziale b d u ywa przyk adów napisanychz wykorzystaniem JBehave i j zyka Java5, a projekt zostanie zbudowany i uruchomionyza pomoc narz dzia Maven6. Raporty z testów b d generowane z wykorzystaniemThucydides7 — biblioteki open source, która u atwia organizowanie i tworzenie raportówz wyników testów BDD. 5 Je li czytelnik nie programuje w Javie, nie ma powodu do obaw. Przyk ady kodu zosta y napisane

w taki sposób, aby by y czytelne dla ka dego, kto ma podstawow wiedz na temat programowania.Narz dzia BDD dla rodowisk .NET, Ruby i Python zostan omówione w rozdziale 5. i dalszych.

6 Maven (http://maven.apache.org/) jest powszechnie u ywanym narz dziem do budowania aplikacjiw Javie.

7 Wi cej informacji na temat biblioteki Thucydides mo na znale w witrynie internetowej tejbiblioteki (http://thucydides.info).

Zawiera zarówno nazw linii, jak i kierunek

Podanosze godzinodjazdówpoci gów,tak abyprzyk adsta sibardziejreprezen-tatywny

Teraz oczekujemy trzech wyników





Kod ród owy dla tego rozdzia u jest dost pny w repozytorium GitHub8 orazw witrynie internetowej wydawnictwa Helion. Aby móc ledzi przyk ad, nale y skon-figurowa rodowisko programistyczne z zainstalowanym nast puj cym oprogra-mowaniem:

Java JDK (przyk adowy kod tworzono w rodowisku Java 1.7.0, ale powinienbezproblemowo dzia a w rodowisku JDK 1.6.0).

Maven 3.0.x. Git.

Serwis GitHub umo liwia dost p do repozytorium na ró ne sposoby. Je li zainstalowali-my aplikacj Git i mamy skonfigurowane konto w witrynie GitHub z dost pem SSH9,

mo emy utworzy klon repozytorium z przyk adowym kodem w nast puj cy sposób:$ git clone [email protected]:bdd-in-action/chapter-2.git

Je li nie ustawili my i nie skonfigurowali my kluczy SSH dla serwisu GitHub, mo emyrównie u y nast puj cego polecenia (Git poprosi o podanie nazwy u ytkownikai has a):

$ git clone https://github.com/bdd-in-action/chapter-2.git10

Po sklonowaniu projektu warto uruchomi polecenie mvn verify w katalogu projektu,aby aplikacja Maven mog a pobra zale no ci potrzebne do jej dzia ania oraz do uru-chomienia projektu. Operacj t trzeba przeprowadzi tylko raz, ale mo e ona trochpotrwa . Uruchom nast puj ce polecenia:$ cd chapter-2$ cd train-timetables$ mvn verify

Je li chcesz kodowa ka dy krok samodzielnie, przejd do katalogu train-timetablesi prze cz si na ga start:$ git checkout start

Gdy to zrobisz, uzyskasz prosty szkielet projektu z prawid owo skonfigurowanym skryp-tem kompilacji programu Maven (plik pom.xml) oraz struktur katalogów, z którejmo esz skorzysta . Je li w dowolnym momencie chcesz przyjrze si przyk adowemurozwi zaniu, uruchom nast puj ce polecenie:$ git checkout master

8 Kod ród owy przyk adów z tego rozdzia u mo na pobra pod adresem https://github.com/bdd-in-

action/chapter-2.9 Dobry przewodnik dotycz cy instalacji narz dzia Git dla ró nych systemów operacyjnych mo na

znale w pomocy serwisu GitHub (https://help.github.com/articles/set-up-git).10Podana cie ka dost pu do repozytorium GitHub oraz wszystkie komendy Git dotycz przyk a-

dowych kodów z oryginalnej wersji ksi ki. Polsk wersj nale y pobra z serwisu FTP wydaw-nictwa Helion pod adresem ftp://ftp.helion.pl/przyklady/bdddzi.zip. Dalszy opis przyk adów dotyczypolskiej wersji j zykowej — przyp. t um.





Pocz tkow struktur projektu pokazano na rysunku 2.2. Jest ona zgodna ze standar-dowymi konwencjami programu Maven. Kod aplikacji b dzie zapisany w katalogusrc/main/java, natomiast kod testu w katalogu src/test/java. Historyjki JBehave trafi dokatalogu src/test/resources/stories. AcceptanceTestSuite jest prost klas uruchamianiatestów bazuj c na frameworku JUnit, która uruchomi historyjki JBehave wewn trzkatalogu src/test/resources i w katalogach podrz dnych.

Rysunek 2.2. Pocz tkowa struktura projektu

2.4.3. Specyfikacje wykonywalne— automatyzacja kryteriów akceptacji

Wyra anie wymaga w formie strukturalnych przyk adów daje wiele korzy ci. Przyk adystanowi doskona y punkt wyj cia do rozmów o potrzebach biznesowych i oczekiwa-niach. W porównaniu z bardziej abstrakcyjnymi specyfikacjami pozwalaj lepiej wyeli-minowa nieporozumienia i nieprawid owe za o enia. Inn wa n korzy ci ze stoso-wania tej metody jest to, e pozwala ona na atwiejsze zautomatyzowanie wymagaw formie testów akceptacyjnych.

Po skonfigurowaniu rodowiska programistycznego nadszed czas, aby zautomaty-zowa przyk ad, który omówili my w poprzednich podrozdzia ach. JBehave, podobniejak wiele narz dzi BDD, wykorzystuje specjalny j zyk do reprezentowania specyfikacjiwykonywalnych w strukturalnym, ale nadal bardzo czytelnym formacie. W JBehavescenariusz mo na wyrazi w sposób zaprezentowany na listingu 2.1.





Listing 2.1. Kryteria akceptacji wyra one w JBehave

Dowiedz si , o której godzinie odje d aj nast pne poci gi do stacji docelowej

Narracja:W celu bardziej efektywnego planowania podró yJako podró nyChc si dowiedzie , jakie nast pne poci gi odje d aj do mojej stacji docelowej

Scenariusz: Znajd optymaln tras pomi dzy stacjami na tej samej linii.

Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramattado Town Hall o 7:58, 8:00, 8:02, 8:11, 8:14, 8:21

Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj o poci gach o: 8:02, 8:11, 8:14

Powy szy opis zawiera niewiele wi cej w porównaniu ze strukturaln wersj przyk adu,który omawiali my wcze niej. Zaczynamy od opisu historyjki i . S owo kluczoweScenariusz (ang. Scenario) oznacza pocz tek ka dego nowego scenariusza. S owakluczowe Zak adaj c (ang. Given) , Gdy (ang. When) i Wtedy (ang. Then) wprowa-dzaj poszczególne cz ci ka dego scenariusza.

W JBehave scenariusze s pogrupowane wed ug historyjek i zapisane w pliku z roz-szerzeniem .story11. Jak mo na zobaczy na rysunku 2.3, plik zawieraj cy definicj tejhistoryjki nosi nazw znajdz_odjazdy_nastepnych_pociagow.story.

Rysunek 2.3. Pliki historyjek JBehave s zorganizowane w postaci katalogów

11Pod tym wzgl dem JBehave nieco ró ni si od systemu Cucumber i narz dzi bazuj cych na systemie

Cucumber, które wykorzystuj pliki .feature. Do tej ró nicy oraz tego, co z niej wynika, powrócimyw rozdziale 5.

Tytu historyjkiOpis historyjki w dowolnej formie

Scenariusz

Warunkiwst pne

Testowane dzia anie

Oczekiwany rezultat





Wszystkie pliki .story mo na umie ci bezpo rednio w katalogu stories. To jednak stajesi niewygodne w przypadku, gdy mamy du liczb plików historyjek. Zamiast tegonajlepiej pogrupowa historyjki w wysokopoziomowe grupy funkcjonalne. Na przyk adw miar rozwoju tego projektu mo e powsta nast puj ca struktura katalogów:

trasy (obliczenia tras i informacje o rozk adzie jazdy); podró ni (indywidualne dane dotycz ce podró y dla pasa erów); powiadomienia (powiadomienia o opó nieniach dla pasa erów).

W celu generowania dokumentacji w ka dym z tych katalogów mo na równie umie-ci plik tekstowy o nazwie narrative.txt12. Zawiera on nazw grupy funkcji oraz krótki

opis tego, co ona obejmuje. Na przyk ad plik narrative.txt dla katalogu trasy mo e wygl -da tak, jak na poni szym listingu.

Listing 2.2. Plik narrative.txt opisuje wysokopoziomow funkcjonalno

Trasy i rozk ady jazdyInformacje w czasie rzeczywistym o rozk adach jazdy i trasach

Mamy teraz specyfikacj wykonywaln . Cho nie ma jeszcze kodu obs uguj cego tenscenariusz, narz dzie JBehave nadal mo e j uruchomi . Aby to sprawdzi , wystarczyprzej do katalogu train-timetables i uruchomi poni sze polecenie:$ mvn verify

Spowoduje to wygenerowanie zbioru raportów w katalogu target/site/thucydides13.Je li otworzysz plik index.html w tym katalogu i klikniesz jedyny test w tabeli Test u do uekranu, powiniene zobaczy ekran podobny do pokazanego na rysunku 2.4.

W tym momencie stworzony scenariusz przesta by prostym dokumentem teksto-wym. Teraz to jest specyfikacja wykonywalna. Mo e by uruchomiona w ramachprocesu automatycznej kompilacji w celu stwierdzenia, czy okre lona funkcja zosta azaimplementowana, czy nie. Gdy takie testy s wykonywane po raz pierwszy, s ozna-czane flag PENDING, co w kategoriach BDD oznacza, e test zosta zautomatyzowany,ale kod, który implementuje testowan funkcj , nie zosta jeszcze napisany. Je li funkcjezostan zaimplementowane, a ich testy akceptacyjne zako cz si sukcesem, s ozna-czone s owem PASSED, co oznacza, e zako czyli my prac w tym obszarze.

Dynamiczna dokumentacja jest jednak czym wi cej ni tylko raportem z testów.Powinna ona równie informowa o stanie wszystkich wyspecyfikowanych wymaga ,nawet tych, dla których jeszcze nie napisano adnych testów. Daje to znacznie pe niej-szy obraz projektu i produktu. Przyk ad raportu o tym poziomie szczegó owo ci mo emy

12Je li plik narrative.txt istnieje, jest równie wykorzystywany przez program Thucydides w celu

generowania dynamicznej dokumentacji, któr zaprezentujemy w dalszej cz ci tej ksi ki.13Maven najpierw ci ga biblioteki, których potrzebuje — ta operacja mo e zaj troch czasu, ale

jest wykonywana tylko raz.

Krótki tytu

Krótki, dowolny opis tej wysokopoziomowej funkcjonalno ci





Rysunek 2.4. Historyjka JBehave wewn trz raportów z testów akceptacyjnych

zobaczy , klikaj c zak adk Requirements w raporcie, który przed chwil wygenerowa-li my (patrz rysunek 2.5). Na rysunku powinna si wy wietli lista wszystkich wysoko-poziomowych wymaga wraz z informacj o tym, ile prac zrealizowano dla ka degoz nich (na tym etapie b dzie to ca kowity brak prac).

Zanim omówimy, w jaki sposób mo na zautomatyzowa podobne scenariusze w Javie,przyjrzyjmy si innemu wariantowi. Bardzo wa n funkcj tworzonej aplikacji jestzdolno informowania podró nych o godzinie, o której dotr do stacji docelowej, je liwyjad ze stacji pocz tkowej w okre lonym czasie. Jerzy poda kilka przyk adów, któremo na wykorzysta w celu stworzenia scenariusza opisuj cego to wymaganie. Zapre-zentowano je na listingu 2.3.

Listing 2.3. Szacowanie godziny przyjazdu

Informacja dla podró nych o czasie przybycia do stacji docelowej

Narracja:W celu bardziej efektywnego planowania podró yJako podró nyChc wiedzie , o której godzinie dotr do stacji docelowej

Scenariusz: Szacowanie czasu przyjazduZak adaj c chc si dosta z <stacja-pocz tkowa> do <stacja-docelowa>I nast pny poci g odje d a o <czas-wyjazdu> na linii <linia>Gdy zapytam o godzin przyjazduWtedy powinienem uzyska nast puj cy szacowany czas przyjazdu: <czas-przyjazdu>

Krótki tytu

Tytuscenariusza

Tutaj zaczynaj siszczegó y scenariusza

W scenariuszuwykorzystanodanez poni szejtabeli





Rysunek 2.5. Dynamiczna dokumentacja powinna równie poinformowa o tym, jakie wymaganiazosta y wyspecyfikowane, nawet wtedy, gdy jeszcze nie istniej dla nich adne testy

Przyk ady:stacja-pocz tkowa| stacja-docelowa | czas-wyjazdu | linia | czas-przyjazduParramatta | Town Hall | 8:02 | Western | 8:29Epping | Central | 8:03 | Northern | 8:48Epping | Central | 8:07 | Newcastle | 8:37Epping | Central | 8:13 | Epping | 8:51

Tutaj g ówn nowo ci jest wykorzystanie tekstowej tabeli do zaprezentowania danychtestowych. Nag ówki tabeli identyfikuj warto ci testowych danych. Ka dy wierszw tabeli reprezentuje odr bny zestaw danych testowych do wykorzystania w tymscenariuszu.

T historyjk mo na umie ci w pliku oblicz_szacowane_czasy_przyjazdu.storyobok pliku z poprzedni historyjk . Spowoduje to dodanie historyjki do zbioru historyjekprzetwarzanych przez JBehave. W ten sposób po uruchomieniu testów stanie si onacz ci dynamicznej dokumentacji (patrz rysunek 2.6).

J zyk u ywany w obu tych scenariuszach jest bardzo zbli ony do j zyka u ywanegoprzez u ytkownika. Poniewa te scenariusze pojawi si w raportach z testów, to dzi kitemu, e do ich stworzenia u yto znanego j zyka, b d one atwiejsze do analizy przeztesterów, u ytkowników ko cowych oraz innych u ytkowników, którzy nie s dewe-loperami.

Nag ówki w tabeli identyfikuj warto ci w testowych danych

Ka dy wierszreprezentujeodr bnyzestaw danychtestowych





Rysunek 2.6. Dynamiczna dokumentacja dla scenariusza zdefiniowanego za pomoc tabeli

2.4.4. Automatyczne testy — implementacja kryteriów akceptacji

Teraz, gdy ju zdefiniowali my i zautomatyzowali my niektóre kryteria akceptacji, mo-emy przyst pi do prawdziwej pracy. Oczywi cie, logika potrzebna do sprawdzenia

kryteriów akceptacji nie napisze si sama: trzeba doda troch kodu, aby testy rzeczy-wi cie wykona y swoj prac .





Zaczniemy od pierwszego scenariusza z listingu 2.1:Scenariusz: Znajd optymaln tras pomi dzy stacjami na tej samej linii.Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramatta do Town Hallo 7:58, 8:00, 8:02, 8:11, 8:14, 8:21

Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj o poci gach o: 8:02, 8:11, 8:14

Kontynuuj c przyk ad z wykorzystaniem JBehave i Javy, mo emy zaimplementowapusty automatyczny test dla tego scenariusza w klasie o nazwie OptimalItinerarySteps.

java, tak jak pokazano na listingu 2.4.

Listing 2.4. Brakuj ca implementacja scenariusza JBehave

package com.bddinaction.chapter2.jbehave.steps;

import org.jbehave.core.annotations.Given;import org.jbehave.core.annotations.Pending;import org.jbehave.core.annotations.Then;import org.jbehave.core.annotations.When;import java.util.List;import org.joda.time.LocalTime;

public class OptimalItinerarySteps { @Given("poci gi linii $line z $lineStart odje d aj ze stacji $departure do $destination o $departureTimes") @Pending public void givenArrivingTrains(String line, String lineStart, String departure, String destination, List<LocalTime> departureTimes) { }

@When("chc podró owa z $departure do $destination o $time") @Pending public void whenIWantToTravel(String departure, String destination, LocalTime time) { } @Then("powinienem uzyska informacj o poci gach o: $viableTrainTimes") @Pending public void shouldFindTheseTrains(List<LocalTime> viableTrainTimes) { }}

Klas t nale y umie ci w pakiecie steps wewn trz pakietu jbehave w katalogu src/test/java (patrz rysunek 2.7). Testy JBehave mog by zaimplementowane w Javie albow innych j zykach platformy JVM, takich jak Groovy lub Scala. Podczas uruchamianiascenariusza JBehave wykorzysta teksty z adnotacji @Given , @When i @Then , abyokre li metod , która b dzie wywo ana w ka dym kroku. Jak wida na listingu,mo na równie przekaza elementy z tekstu scenariusza do metod testowych w postaciparametrów.

Krok Zak adaj c

Oznaczenie tego kroku jako zaleg ego

Krok Gdy

Krok Wtedy





Rysunek 2.7. Struktura pakietu zawieraj ca now klas z implementacj kroku

Je li pozostawimy implementacj testu w takiej postaci, jak pokazano na listingu, todzi ki adnotacji @Pending uzyskamy pewno , e ten test wygeneruje dok adnie takiesame wyniki, jak pokazano na rysunku 2.4. Ale ju wkrótce dodamy implementacjka dej metody, tak by przekszta ci ten kod w dzia aj cy w pe ni test.

Te kroki spe niaj rol punktu wyj cia dla kodu produkcyjnego: mówi , co b dzietrzeba zbudowa , aby dostarczy opisywan funkcj . Zespo y praktykuj ce BDD zwy-kle zaczynaj od okre lenia wyniku, którego potrzebuj , i dzia aj wstecz. Spróbujmywi c zobaczy , jak ten sposób dzia ania b dzie wygl da w tym przyk adzie.

Zaczniemy od kroku @Then, który wyra a oczekiwany wynik. W istocie chcemy, abyus uga zwraca a list proponowanych godzin odjazdów poci gów, które pasuj do ocze-kiwanej pory. Oto jeden ze sposobów wyra enia tego warunku:@Then("powinienem uzyska informacj o poci gach o: $expectedTrainTimes")public void shouldBeInformedAbout(List<LocalTime> expectedTrainTimes) { assertThat(proposedTrainTimes).isEqualTo(expectedTrainTimes);}

JBehave dopasuje pierwsz linijk scenariusza, wyodr bni z niej list oczekiwanychgodzin (oznaczonych w adnotacji @Then zmienn $expectedTrainTimes) i przeka e je jakoparametr do metody. Zwró my uwag , e w tym przyk adzie usun li my równie adno-tacj @Pending. Dzi ki temu JBehave b dzie wiedzia , e powinien uruchomi ten krok.Ale ten test jeszcze si nie skompiluje — nadal trzeba zdecydowa , sk d b dzie odje -d a proponowany poci g.

BDD pomaga odkry techniczny projekt potrzebny w celu dostarczenia cech funk-cjonalnych spe niaj cych cele biznesowe. Za ó my, e zdecydowali my si zaimplemen-towa t aplikacj za pomoc kilku ró nych us ug sieciowych. Na przyk ad mo emypotrzebowa us ugi, która dostarcza informacji na temat godzin odjazdów do witrynyWWW lub aplikacji mobilnej. Ta us uga jeszcze nie istnieje, wi c trzeba odkry , copowinna robi . Jednym z najbardziej skutecznych sposobów, aby to zrobi , jest poprostu napisanie kodu, który chcieliby my mie . To pozwala na projektowanie czystego,czytelnego i samodokumentuj cego si interfejsu API.





Na przyk ad, aby znale czasy odjazdu nast pnych poci gów z danej stacji, mo nawykorzysta jedn , bardzo prost implementacj :proposedTrainTimes = itineraryService.findNextDepartures(departure, destination, startTime);

Je li ten kod zintegrujemy z krokiem @When, otrzymamy co takiego:List<LocalTime> proposedTrainTimes;

@When("chc podró owa z $departure do $destination o $startTime")public void whenIWantToTravel(String departure, String destination, LocalTime startTime) { ItineraryService itineraryService = new ItineraryService(); proposedTrainTimes = itineraryService.findNextDepartures(departure, destination, startTime);}

Aby to kryterium akceptacji mog o przej , nale y zaimplementowa metod findNextDepartures(). Jednak zanim to zrobimy, musimy prze czy si z testowania akcepta-

cyjnego na testy jednostkowe. Jak mo na zauwa y , testy akceptacyjne s u do zade-monstrowania wysokopoziomowych zachowa aplikacji, natomiast testy jednostkowe su ywane do budowania komponentów, które b d u ywane do zaimplementowaniatego zachowania. Testy akceptacyjne zazwyczaj u ywaj pe nego lub prawie pe negostosu aplikacji, natomiast testy jednostkowe koncentruj si na poszczególnych kom-ponentach w izolacji. Testy jednostkowe u atwiaj skoncentrowanie si na prawid o-wym zaimplementowaniu konkretnej klasy oraz okre leniu innych us ug lub kompo-nentów, których ona potrzebuje. Testy jednostkowe u atwiaj równie wykrywaniei izolowanie b dów lub regresji. W celu spe nienia kryterium akceptacji zwykle piszesi wiele krótkich testów jednostkowych (patrz rysunek 2.8).

W celu napisania tych testów jednostkowych mo na by u y konwencjonalnego fra-meworka, na przyk ad JUnit. Poniewa jednak ta ksi ka jest o BDD, skorzystamy z bar-dziej specyficznego dla BDD narz dzia testów jednostkowych o nazwie Spock. Spockjest prost w u yciu i ekspresywn bibliotek testowania w stylu BDD dla aplikacjiw j zykach Java i Groovy. Z tego narz dzia b dziemy intensywnie korzysta w dalszejcz ci tej ksi ki.

Groovy jest j zykiem dynamicznym zbudowanym na bazie Javy, który zawiera wielew asno ci z takich j zyków, jak Ruby i Python. To bardzo ekspresywny j zyk, którywietnie nadaje si do sprawdzania wyników — pozwala to robi w bardzo czytelny

i zwi z y sposób.Zaczniemy od testowania kryterium akceptacji opisanego w scenariuszu JBehave na

listingu 2.1, ale na poziomie testu jednostkowego. W Spock stworzymy klas Groovyo nazwie WhenCalculatingArrivalTimes.groovy i umie cimy j w odpowiednim pakieciew katalogu src/test/groovy14. Klasa ta mo e mie nast puj c posta :

14W przyk adowym rozwi zaniu klas t umie cili my w pakiecie com.bddinaction.chapter2.services.

Krok Gdy (When)

Przekazywanieparametrów z krokuGdy (When)

Wyszukiwaniegodzinnast pnychodjazdów

Utworzenienowej us ugiItineraryService





Rysunek 2.8. Aby spe ni kryterium akceptacji, zazwyczaj trzeba napisa wieleniskopoziomowych testów jednostkowych w stylu TDD. W przyk adzie zaprezentowanymw tym rozdziale wykorzystano framework JBehave do implementacji kryterium akceptacjioraz framework Spock dla testów jednostkowych

Pisanie testów jednostkowych z wykorzystaniem Spock

Za pomoc narz dzia Spock testy jednostkowe pisze si w formie „specyfikacji”, przyu yciu bardzo czytelnej struktury „Given... When... Then”, podobnej do tej, która jest sto-sowana w scenariuszach JBehave. Na przyk ad, gdyby my chcieli za pomoc frameworkaSpock przetestowa klas Calculator, mogliby my u y kodu w nast puj cej postaci:

def "powinna wylicza sum dwóch liczb"() { given: "dwie liczby" int a = 1 int b = 2 when: "dodajemy liczby do siebie" def calculator = new Calculator() int sum = calculator.add(a,b) then: "wynik powinien by sum dwóch liczb" sum == 3

Wielu programistów Javy pisze testy jednostkowe za pomoc frameworka Spock, ponie-wa pozwala on pisa zwi z e i opisowe testy za pomoc kodu mniej szablonowego odtego, który by by potrzebny w przypadku zastosowania j zyka Java.

package com.bddinaction.chapter2.services

import org.joda.time.LocalTimeimport spock.lang.Specification

class WhenCalculatingArrivalTimes extends Specification { ItineraryService itineraryService; def "powinna obliczy prawid ow godzin przyjazdu"() {

Definiowanie specyfikacji

Klauzula given

Klauzula when

Klauzula then

Odpowiednik instrukcji assert sum == 3

Testy SpockmuszrozszerzaklasSpecification

Sprawdzanewymaganie





given: itineraryService = new ItineraryService(); when: def proposedTrainTimes = itineraryService.findNextDepartures("Parramatta", "Town Hall", at('8:00')); then: proposedTrainTimes == [at('8:02'), at('8:11'), at('8:14' )] } def at(String time) { def hour = Integer.valueOf(time.split(':')[0]) def minute = Integer.valueOf(time.split(':')[1]) new LocalTime(hour.toInteger(), minute.toInteger()) }}

Ogólnie rzecz bior c, ta specyfikacja realizuje to samo, co test JBehave. Tworzy nowus ug tras , szuka nast pnych odjazdów na trasie Parramatta i Town Hall, pocz wszyod 8:00 , a nast pnie sprawdza, czy odpowiada to oczekiwanym godzinom . Kiedytest przejdzie, mo emy mie pewno , e klasa ItineraryService realizuje oczekiwaneoperacje.

Oczywi cie, je li uruchomimy t specyfikacj , to zako czy si ona niepowodzeniem,poniewa na razie nie napisali my jeszcze adnego kodu ród owego aplikacji. Teraznadszed czas na napisanie tego kodu. Zobaczmy, jak mog aby wygl da metoda find

NextDepartures():public List<LocalTime> findNextDepartures(String departure, String destination, LocalTime startTime) { List<Line> lines = timetableService.findLinesThrough(departure, destination); List<LocalTime> allArrivalTimes = getArrivalTimesOnLines(lines, departure); List<LocalTime> candidateArrivalTimes = findArrivalTimesAfter(startTime, allArrivalTimes); return atMost(3, candidateArrivalTimes);}

private List<LocalTime> atMost(int max, List<LocalTime> times) { return Lists.partition(times, max).get(0);}

Zadaniem us ugi tras jest obliczenie informacji na temat odjazdów i szczegó ów podró yna podstawie aktualnych rozk adów jazdy. Do tego celu potrzebne s dane dotycz cerozk adu jazdy, ale jeszcze nie napisali my adnego kodu, który móg by oblicza teinformacje: rozk ady jazdy s skomplikowane i stanowi odr bn dziedzin problemu.Zgodnie z dobrymi praktykami projektowymi powinni my u y odr bnej us ugi, któradostarczy danych dotycz cych rozk adu jazdy do us ugi tras. W kodzie zamieszczo-nym powy ej zadeklarowano obiekt timetableService , który jest odpowiedzialny zat operacj .

„Zak adaj c mam us uginformacji o trasach”

„Gdy szukamnast pnychodjazdów”

To powinienem uzyska propozycjnast puj cych godzin

Funkcja narz dziowau atwiaj ca zainicjowaniewarto ci godzin

Jakie linie kursuj pomi dzy tymi dwoma stacjami?

O jakichgodzinachpoci gina tych liniachwyje d ajze stacjipocz tkowej?

Jakie poci giprzyje d ajtu po podanejgodziniestartu?

Interesuje mnie informacjatylko o pierwszych trzech z nich

Metoda narz dziowapozwalaj ca zwrócido trzech godzinprzyjazdów.





Pierwsz rzecz , jak ten kod robi, jest znalezienie linii kolejowej, która pozwolipasa erowi na podró ze stacji pocz tkowej do stacji docelowej. Jest to domena us ugirozk adu jazdy, zatem prosimy j o dostarczenie wykazu linii od jednej stacji do dru-giej . W tym kontek cie linia reprezentuje cie k , któr poruszaj si poci gi z jed-nej stacji do drugiej, w okre lonym kierunku. Pami tajmy, e us uga rozk adu jazdy niema jeszcze adnych metod, zatem w a nie odkryli my co , co powinna robi us uga roz-k adu jazdy.

Po uzyskaniu listy linii mo emy znale dla ka dej z nich godziny przyjazdu poci -gów na stacj pocz tkow . Istnieje kilka sposobów, aby to zrobi . Wa ne jest jednak to,e zadanie to oddelegujemy do innej metody i zajmiemy si g ówn logik biznesow .

Ostatni rzecz , jak ta metoda musi robi , jest znalezienie godzin przyjazdów podanej godzinie pocz tkowej i zwrócenie kolejnych trzech godzin odjazdu .Kompletny kod ród owy tego rozwi zania mo na znale w serwisie FTP wydaw-

nictwa Helion15; skoncentrujmy si jednak na metodzie getArrivalTimesOnLines() zamiesz-czonej poni ej:private List<LocalTime> getArrivalTimesOnLines(List<Line> lines, String station) { TreeSet<LocalTime> allArrivalTimes = Sets.newTreeSet(); for(Line line : lines) { allArrivalTimes.addAll( timetableService.findArrivalTimes(line,station)); } return new ArrayList<LocalTime>(allArrivalTimes);}

Ta metoda jest interesuj ca, poniewa wskazuje na inn operacj , któr powinna reali-zowa us uga rozk adu jazdy. Logika nie jest skomplikowana — stworzenie prostejkolekcji godzin przyjazdu dla linii przechodz cych przez dan stacj . Linia jest pro-stym obiektem dziedzinowym z nazw , stacj wyjazdu i list stacji nale cych do tejlinii16.

Aby jednak metoda getArrivalTimesOnLines() zadzia a a, musimy zna planowanegodziny przyjazdu poci gów z danej linii na stacj wyjazdu. Informacj t powinni myuzyska z us ugi rozk adu jazdy.

Oznacza to, e potrzebujemy obiektu TimetableService, który realizuje nast puj cedzia ania:

Wyszukuje linie przebiegaj ce przez dowolne dwie stacje. Znajduje godziny przyjazdu na okre lon stacj poci gów ze wskazanej linii.

Mo emy sformalizowa to, czego potrzebujemy, w kroku Given specyfikacji Spock, two-rz c us ug , która „udaje” us ug rozk adu jazdy — zachowuj c si dok adnie tak, jaktego chcemy. Musimy tylko zapewni , aby us uga tras prawid owo przetwarza a danedostarczone z us ugi rozk adu jazdy. Mo na to zrobi za pomoc poni szego kodu:

15 Kod ród owy przyk adów z tego rozdzia u mo na pobra pod adresem ftp://ftp.helion.pl/przyklady/

bdddzi.zip.16 Dla uproszczenia w przyk adowym kodzie zamieszczono pe n implementacj klasy Line.

Pobraniegodzinprzyjazdu





TimetableService timetableService = Mock(TimetableService)

def "powinna obliczy prawid ow godzin przyjazdu"() { given:

def westernLine = Line.named("Western").departingFrom("Emu Plains") timetableService.findLinesThrough("Parramatta", "Town Hall") >> [westernLine] timetableService.findArrivalTimes(westernLine, "Parramatta") >> [at(7,58), at(8,00), at(8,02), at(8,11), at(8,14), at(8,21)]

when: def proposedTrainTimes = itineraryService.findNextDepartures("Parramatta", "Town Hall", at(8,00));

then: proposedTrainTimes == [at(8,02), at(8,11), at(8,14)]}

Ten kod konfiguruje makiet (ang. mock) us ugi rozk adu jazdy w celu zamodelowaniadzia a , jakie powinna realizowa prawdziwa us uga rozk adu jazdy. Wiemy, e powinnaona poinformowa nas, jakie linie przebiegaj przez dowolne dwie stacje i o którejgodzinie poci gi z danej linii przyje d aj do wskazanej stacji . Symbol >> dla fra-meworka Spock jest skrótem stwierdzenia: „Gdy wywo am t metod z tymi parame-trami, zwró takie warto ci”.

Aby powy szy kod si skompilowa , potrzebujemy klasy TimetableService. W Javiezwykle zdefiniowaliby my interfejs. Pozwoli oby to na od o enie w a ciwej implemen-tacji klasy TimetableService na pó niej — po zaimplementowaniu klasy ItinerarySer

vice. Metody, których potrzebuje klasa TimetableService, zdefiniowali my w i ,zatem ten interfejs mo e wygl da nast puj co:package com.bddinaction.chapter2.services;

import com.bddinaction.chapter2.model.Line;import org.joda.time.LocalTime;

import java.util.List;

public interface TimetableService { List<LocalTime> findArrivalTimes(Line line, String targetStation); List<Line> findLinesThrough(String departure, String destination);}

Ostatnim elementem uk adanki jest metoda findArrivalTimesAfter(), która zwraca listgodzin odjazdów po okre lonej godzinie, tak jak pokazano w poni szej przyk adowejimplementacji:private List<LocalTime> findArrivalTimesAfter(LocalTime startTime, List<LocalTime> times) { List<LocalTime> viableArrivalTimes = Lists.newArrayList();

Utworzenie makiety us ugi rozk adu jazdy.

Definiujemylini kolejow

Gdy zapytamy, które linie przechodzprzez stacje Parramatta i Town Hall,

makieta us ugi rozk adu jazdyzwraca t lini kolejow .

Makieta us ugi rozk adu jazdy zwraca równieprawid owe godziny przyjazdu na stacj Parramatta.





for(LocalTime arrivalTime : times) { if (arrivalTime.isAfter(startTime)) { viableArrivalTimes.add(arrivalTime); } } return viableArrivalTimes;}

Je li teraz uruchomimy ten test za pomoc polecenia mvn verify, powinien on przej ,co pokazuje nam, e teraz mamy dzia aj c us ug tras. Jednak na tym praca jeszcze sinie ko czy. Dzia anie us ugi tras bazuje na za o eniu, e us uga rozk adu jazdy prawi-d owo wykonuje swoje zadanie i u ywa „atrapy” us ugi rozk adu jazdy (znanej pod nazwnamiastki — ang. stub — lub makiety — ang. mock), aby unikn konieczno ci wykorzy-stania rzeczywistej implementacji. Jest to bardzo skuteczny sposób zbudowania us ugitras, poniewa pozwala skoncentrowa si wy cznie na logice biznesowej tej us ugi. Alewracaj c do spe nienia sformu owanego kryterium akceptacji, nale y równie zaimple-mentowa us ug rozk adu jazdy.

Zachowanie zdefiniowane dla makiety us ugi rozk adu jazdy dostarcza bardzo pre-cyzyjnych niskopoziomowych wymaga co do zachowania tej us ugi. Definicja ta b dziepunktem wyj cia do implementacji tej us ugi. Nast pnie napiszemy nowy test Spock,o nazwie WhenFindingLinesThroughStations.groovy (ponownie w pakiecie com.bddinaction.

chapter2.services), który opiera si na tych wymaganiach i bardziej szczegó owo opi-suje, co us uga rozk adu jazdy powinna robi :package com.bddinaction.chapter2.services

import com.bddinaction.chapter2.model.Lineimport spock.lang.Specification

class WhenFindingLinesThroughStations extends Specification {

def timetableService = new TimetableService()

def "powinna znale prawid owe linie pomi dzy dwoma stacjami"() { when: def lines = timetableService.findLinesThrough(departure, destination) then: def expectedLine = Line.named(lineName). departingFrom(lineDeparture) lines == [expectedLine] where:departure | destination | lineName | lineDeparture"Parramatta" | "Town Hall" | "Western" | "Emu Plains""Town Hall" | "Parramatta" | "Western" | "North Richmond""Strathfield" | "Epping" | "Epping" | "City" }}

Ten test bazuje na przyk adzie kryterium akceptacji i s u y do zbadania wymaga . Aletesty jednostkowe powinny by bardziej dok adne ni akceptacyjne. W tym przypadkuskorzystali my z tabeli , podobnej do tabeli z listingu 2.3, wykorzystywanej przez

Testowanedzia anie.

Us uga rozk adujazdy powinnazwróci te linie

Wykorzystamyprzyk adowe danez tej tabeli




2.5. Utrzymanie 81

framework JBehave. To sprawia, e atwo doda bardziej wyczerpuj cy zbiór przyk a-dów, a o to nam chodzi na tym poziomie szczegó owo ci.

Po zaimplementowaniu metody findLinesThrough() mo emy przej do implemento-wania kolejnej potrzebnej funkcji: wyszukiwania godzin przyjazdu na wskazan stacj .Do tego celu mo na zastosowa podobne podej cie — zacz od napisania nowej specy-fikacji Spock.

WICZENIE 2.1. Napisz testy jednostkowe dla funkcji „znajd godziny przy-jazdu na podan stacj dla danej linii” i zaimplementuj odpowiedni kod.

Istnieje wiele mo liwych sposobów implementacji tej us ugi. W tym miejscu nieb dziemy zag bia si w szczegó y. Po drodze jednak mo emy odkry inne us ugi lubkomponenty, które b d nam potrzebne. Te komponenty mo na zast pi makiet ,a nast pnie zaimplementowa . Kiedy ju nie b dzie klas-atrap do zaimplementowania,kryterium akceptacji uruchomi si poprawnie, co oznacza zako czenie implementacjifunkcji.

2.4.5. Testy jako dynamiczna dokumentacja

Po zaimplementowaniu funkcji powinno by mo liwe uruchomienie testów. Obok testówzaleg ych (ang. pending) powinny si pojawi spe nione kryteria akceptacji (patrz rysu-nek 2.9). W przypadku stosowania takich praktyk jak BDD ten wynik to co wi cej nipo prostu wska nik, e aplikacja spe nia wymagania biznesowe. Przechodz cy test akcep-tacji jest równie konkretn miar post pów. Zaimplementowany test albo przechodzi,albo ko czy si niepowodzeniem. Najlepiej, je li wszystkie kryteria akceptacji dlafunkcji s zautomatyzowane i pomy lnie przechodz . Wtedy mo na powiedzie , e tafunkcja jest sko czona i gotowa do produkcji.

Stan testów daje wi cej ni tylko ocen jako ci aplikacji — jest on wyra nym wska -nikiem tego, w jakim miejscu w procesie rozwoju si znajdujemy. Proporcja pomi dzyprzechodz cymi testami a ca kowit liczb zdefiniowanych kryteriów akceptacji dajedobry obraz tego, ile pracy zrealizowano do tej pory, a ile pozosta o do zrobienia. Ponadto,dzi ki ledzeniu liczby zako czonych automatycznych testów akceptacji w porównaniuz liczb zaleg ych testów mo na uzyska obraz post pów projektu w czasie.

Pisanie testów w takim narracyjnym stylu przynosi tak e inne korzy ci. Ka dy auto-matyczny test akceptacji staje si udokumentowanym, dzia aj cym przyk adem tego,jak mo na wykorzysta system do spe niania szczegó owych wymaga biznesowych.A w przypadku, gdy raporty z testów s w postaci stron WWW, dzia aj ce przyk adyb d nawet zilustrowane zrzutami ekranu.

2.5. UtrzymanieW wielu organizacjach deweloperzy, którzy pracowali w pocz tkowym projekcie, niezajmuj si utrzymaniem aplikacji, gdy ta zostanie przekazana do produkcji. Zamiast tegozadania utrzymania aplikacji s przekazywane do zespo u piel gnacyjnego (ang. Businessas Usual — BAU — dos . biznes jak zwykle). W tego rodzaju rodowisku specyfikacje





Rysunek 2.9. W raportach z testów powinna si teraz pojawi informacja o tym, e test przechodzi

Rola testerów. Automatyczne testowanie akceptacyjne a kontrola jako ci

Automatyczne wdra anie aplikacji do produkcji, gdy przechodz automatyczne testyakceptacji, wymaga du o dyscypliny i ogromnego zaufania do jako ci i kompletno cizautomatyzowanych testów. Jest to godny cel i wielu organizacjom uda o si go osi -gn , ale w wi kszo ci przypadków to nie jest takie proste.

W typowych rodowiskach korporacyjnych testerzy zazwyczaj b d przeprowadzali conajmniej kilka testów r cznych przed wdro eniem aplikacji do produkcji. Ale je li wyni-ki testów automatycznych s oczywiste i widoczne, mog one zaoszcz dzi zespo owiQA wielu dni lub tygodni, które normalnie by yby przeznaczone na testy regresji lubpodstawowe mechaniczne testy. Dzi ki temu cz onkowie zespo u mog skupi si nabardziej interesuj cych zadaniach zwi zanych z testowaniem. To z kolei mo e znacznieprzyspieszy cykl publikacji.




2.5. Utrzymanie 83

wykonywalne i dynamiczna dokumentacja s wietnym sposobem na usprawnienie pro-cesu przekazywania aplikacji do produkcji, poniewa dostarczaj dzia aj cych przyk adówcech funkcjonalnych aplikacji wraz z ilustracjami kodu, który obs uguje te cechy.

Ponadto, specyfikacje wykonywalne znacznie u atwiaj zespo om zajmuj cym siutrzymaniem wdra anie zmian lub poprawek. Zobaczmy na prostym przyk adzie, jak todzia a. Za ó my, e u ytkownicy poprosili o cech funkcjonaln wy wietlaj c infor-macje o poci gach, które maj przyby w ci gu najbli szych 30 minut, a nie tylko nast p-nych 15, jak obecnie.

Oto scenariusz zwi zany z tym wymaganiem:Dowiedz si , o której godzinie odje d aj nast pne poci gi do stacji docelowej

Narracja:W celu bardziej efektywnego planowania podró yJako podró nyChc si dowiedzie , jakie nast pne poci gi odje d aj do mojej stacji docelowej

Scenariusz: Znajd optymaln tras pomi dzy stacjami na tej samej linii.Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramatta do Town Hallo7:58, 8:00, 8:02, 8:11, 8:14, 8:21Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj o poci gach o: 8:02, 8:11, 8:14

Ten scenariusz wyra a nasz bie cy sposób rozumienia wymagania: aplikacja obecniezachowuje si w ten sposób i mamy automatyczne kryterium akceptacji oraz testy jed-nostkowe, które to udowadniaj .

Jednak nowe danie u ytkownika wszystko zmieni o. Scenariusz teraz powinienwygl da nast puj co:

Scenariusz: Znajd optymaln tras pomi dzy stacjami na tej samej linii.Zak adaj c poci gi linii Western z Emu Plains odje d aj ze stacji Parramatta do Town Hallo 7:58, 8:00, 8:02, 8:11, 8:14, 8:21, 8:31, 8:36Gdy chc podró owa z Parramatta do Town Hall o 8:00Wtedy powinienem uzyska informacj o poci gach o: 8:02, 8:11, 8:14, 8:21

Po uruchomieniu tego nowego scenariusza oka e si , e zako czy si on niepowodze-niem (patrz rysunek 2.10). Wszystko w porz dku! To pokazuje, e aplikacja nie robi tego,czego daj wymagania. Mamy teraz punkt wyj cia do implementacji tej modyfikacji.

Mo emy u y testów jednostkowych do wyizolowania kodu, który powinien zostazmieniony. Nale y zaktualizowa specyfikacj Spock „powinna obliczy prawid owgodzin przyjazdu” tak, aby uwzgl dni a nowe kryterium akceptacji:def "powinna obliczy prawid ow godzin przyjazdu"() { given: def westernLineFromEmuPlains = Line.named("Western").departingFrom("Emu Plains")

timetableService.findLinesThrough("Parramatta","Town Hall") >> [westernLineFromEmuPlains]

Teraz chcemy wiedzie o wszystkich poci gach odje d aj cych w ci gu 30 minut.

Potrzebujemy wi cej przyk adowych godzin odjazdu.





Rysunek 2.10. Nieprzechodz ce kryterium akceptacji ilustruje ró nic pomi dzy tym, jakie swymagania, a tym, co aplikacja obecnie robi

timetableService .findArrivalTimes(westernLineFromEmuPlains, "Parramatta") >> [at(7,58), at(8,00), at(8,02), at(8,11), at(8,14), at(8,21), at(8,31), at(8,36)] when: def proposedTrainTimes = itineraryService. findNextDepartures("Parramatta", "Town Hall", at(8,00)); then: proposedTrainTimes == [at(8,02), at(8,11), at(8,14), at(8,21)]}

To z kolei pomaga wyodr bni kod, który trzeba zmieni wewn trz klasy ItineraryService. Po wykonaniu tych dzia a poprawne zaktualizowanie kodu powinno przyj

nam znacznie atwiej.Wprowadzenie wi kszych zmian b dzie oczywi cie wi za o si z wi ksz prac , ale

dla modyfikacji dowolnych rozmiarów obowi zuje taka sama zasada. Je li danie zmianydotyczy modyfikacji istniej cych cech funkcjonalnych, trzeba zaktualizowa auto-matyczne kryterium akceptacji tak, by uwzgl dnia o nowe wymaganie. Je li zmiana jestpoprawk b du, który nie zosta wykryty przez kryterium akceptacji w obecnej postaci,to najpierw trzeba napisa nowe automatyczne kryterium akceptacji, aby powtórzyb d, nast pnie naprawi b d i na koniec u y kryterium akceptacji, aby wykaza , eb d zosta usuni ty. A je li zmiana jest wystarczaj co du a do tego, aby istniej ce kry-terium akceptacji sta o si zb dne, mo na usun stare kryterium akceptacji i napisanowe.

Us uga-atrapa zwraca teraz wi cej kursów.

Teraz oczekujemy od us ugi traszwrócenia czterech godzin.





2.6. PodsumowanieW tym rozdziale zapoznali my si z ogólnym cyklem ycia projektu BDD. W szczegól-no ci dowiedzieli my si , e:

Zrozumienie podstawowych celów biznesowych projektu pozwala odkry funkcjei historyjki, które przyczyniaj si do osi gni cia tych celów biznesowych.

Funkcje opisuj operacje, które pomog u ytkownikom i interesariuszom osi -gn swoje cele.

Funkcje mo na podzieli na historyjki, które s atwiejsze do stworzenia i dostar-czenia za jednym razem.

Skutecznym sposobem opisywania i omawiania funkcji s konkretne przyk ady. Przyk ady, wyra one w pó strukturalnej notacji „Zak adaj c... Gdy... Wtedy”,

mo na zautomatyzowa , tworz c automatyczne kryteria akceptacji. Kryteria akceptacji steruj niskopoziomowymi zadaniami implementacji. Poma-

gaj zaprojektowa i napisa tylko taki kod, którego naprawd potrzebujemy. Struktur BDD w stylu „Zak adaj c... Gdy... Wtedy” mo na równie stosowa

w testach jednostkowych. Automatyczne kryteria akceptacji dokumentuj równie dostarczone funkcje

w postaci dynamicznej dokumentacji. Zautomatyzowane kryteria akceptacji i testy jednostkowe w stylu BDD znacznie

u atwiaj utrzymanie aplikacji.

W kolejnych rozdzia ach omówimy znacznie bardziej szczegó owo ka dy z tematówzasygnalizowanych w niniejszym rozdziale. Poka emy równie , jak mo na zastosowaomówione podej cia w praktyce, stosuj c ró ne narz dzia i technologie.




Skorowidz

Aadnotacja

@FindBy, 271@Pending, 74

aktor, 110analityk biznesowy, 28analiza wymaga , 60aplikacje

AJAX, 265webowe, 246

architekturaMVC, 291zorientowana na us ugi, SOA, 299

ATDD, Acceptance-Test-DrivenDevelopment, 38

automatyczna dokumentacja, 51automatyczne

kryteria akceptacji, 120testowanie akceptacyjne, 82testy, 28, 72testy aplikacji webowych, 246

automatyczny proces budowy, 374automatyzowanie

procesu konfiguracji testu, 228scenariuszy, 179, 182

kryteriów akceptacji, 67, 245, 283, 317w .NET, 211w JavaScript, 216w Javie, 202w Pythonie, 207

webowych kryteriów akceptacji, 251

BBAU, Business as Usual, 81BDD, Behavior-Driven Development, 23

bibliotekaGeb, 279Jasmine, 341Selenium WebDriver, 246Spock, 47Thucydides, 279WatiN, 279Watir, 279WebDriver, 252, 279

bibliotekiautomatyzacji, 180obs ugi kroków, 240

bramy jako ci, 380budowanie, 373

niew a ciwego oprogramowania, 29, 33w a ciwego oprogramowania, 32

Ccecha funkcjonalna, feature, 39, 62, 95, 114,

119–123, 134fragmenty, 126historyjki u ytkowników, 128, 131Ró nica dla rynku, 116Wa no dla misji, 116zdolno ci, 122

cechyo minimalnym wp ywie, 117partnerskie, 117równowa ne, 116wyró niaj ce, 116

cele biznesowe, 60, 89, 95, 102celowe odkrywanie, 120, 144ci g a integracja, CI, 181, 378ci g e

dostawy, 181, 380wdra anie, 181




400 Skorowidz

cykl sprz enia zwrotnego, 378czytelno testów, 267

Ddane tabelaryczne, 190DDD, Domain-Driven Design, 37definicje kroków, 182, 199, 206, 210, 317

Behave, 209Cucumber-JVM, 203JBehave, 195

definiowaniecech funkcjonalnych, 119wymaga , 87wymaga niefunkcjonalnych, 304

dokumentacja, 49automatyczna, 51dynamiczna, 49–51, 71, 81, 345, 354, 364,

371domena, 318dostarczanie

cech funkcjonalnych, 64dokumentacji, 366

dzia aj ce oprogramowanie, 145

Eedytowanie pliku, 212efektywna implementacja BDD, 193elementy strony WWW, 255eposy, epic, 120, 132

Ffeature injection, 91firma Flying High, 91formu a wizji, 97framework

JBehave, 81, 194JUnit, 75Spock, 76

frameworki testów jednostkowych, 339, 341funkcje, 60funkcjonalno wysokopoziomowa, 69

GGherkin, 37gotowo cech funkcjonalnych, 356grupowanie cech funkcjonalnych, 363

Hhaki, hooks, 175haki inicjalizacji, 225, 229

w Behave, 232w cucumber-jvm, 231w JBehave, 229w Specflow, 232

has a, 139hierarchia, 133historyjka JBehave, 70historyjki u ytkownika, user stories, 120, 132

Iidentyfikowanie

celów biznesowych, 99elementów strony WWW, 255, 258, 261interesariuszy, 110zdolno ci, 112

ilustrowaniecech funkcjonalnych, 134historyjek, 63

impact mapping, 91implementacja, 64

definicji kroków, 186, 317kodu produkcyjnego, 330kroków, 74, 187, 218kryteriów akceptacji, 72minimalna, 331natychmiastowa, 331scenariusza, 73z o onych funkcjonalno ci, 325interfejsu WebDriver, 255

inicjowanie bazy danych, 228instalowanie

systemu Behave, 208narz dzi BDD, 186narz dzia JBehave, 194

interakcjez elementami stron WWW, 263z systemem, 241

interesariusz, 33, 61, 110, 153




Skorowidz 401

interfejsu ytkownika, UI, 246WebDriver, 255

Kklasa

Groovy, 75TimetableService, 79

klasy fixture, 367kod z zewn trz do wewn trz, 314, 315komentarze, 159konfigurowanie

danych specyficznych, 233narz dzia JBehave, 194projektu Cucumber-JVM, 202SpecFlow, 211systemu Cucumber-JS, 216testu, 228

kontekst, 168, 338kontrola

jako ci, 82zmian, 103

korzystanie z haków, 229korzy ci, 52koszty, 52

utrzymania, 54krok

@Then, 74Gdy, 166, 197Wtedy, 167Zak adaj c, 165, 197

krokiBehave, 209Cucumber-JVM, 203JBehave, 195oczekuj ce, 207SpecFlow, 213t a, 169

kryteria akceptacji, 37, 58, 64, 72, 84, 228,385, 388

Llogika biznesowa, 295

cze, 257czenie kroków, 209

Mmakieta, mock, 80, 332mapowanie wp ywu, impact mapping, 91,

106marnotrawstwo, 52metodologia

Agile, 53Unified Process, 108

metodologie iteracyjne, 53mistrz m yna, scrum master, 361model

domeny, 318dopasowania do celów, 91, 114dopasowania do celu, 115

Nnamiastka, stub, 80, 332narz dzia

analizy wymaga , 37BDD, 186testów jednostkowych, 75, 313, 336

narz dzieBehat, 65Cucumber, 64, 65Cucumber-JVM, 202Git, 65Jasmine, 343JBehave, 46, 59, 65, 194Maven, 65NSpec, 342RSpec, 339SpecFlow, 65Spock, 75, 76Thucydides, 193

niewiadome, 34niew a ciwe budowanie oprogramowania, 29,

33niskopoziomowa specyfikacja, 324

wykonywalna, 47techniczna, 333

notacja <...>, 44

Oobiekt TimetableService, 78obiekty stron, 242, 269, 273, 276, 279oddzielanie warstw, 237




402 Skorowidz

odkrywanie projektu, 306ograniczenia wiedzy, 32opcja, 140opcje realne, 142opisywanie

cech funkcjonalnych, 94, 211funkcji, 60scenariuszy, 156

oprogramowanie sterowane testami, 311organizowanie

dynamicznej dokumentacji, 362, 363, 364scenariuszy, 171

o u ytkownika, 390

Pparametry tabelaryczne, 198persony, personas, 225, 235pisanie

dobrych celów biznesowych, 100ekspresywnych kroków, 165–167plików opisu, 217testów akceptacji, 225wykonywalnych scenariuszy, 154

plik opisu cechy funkcjonalnej, 43, 154, 172p ynne

asercje, 347kodowanie, 346selektory, 281

pocz tkowa struktura projektu, 67podzia

cech funkcjonalnych, 62odpowiedzialno ci, 306

pokrycie cech funkcjonalnych, 356, 357pola

tekstowe, 263wyboru, 264

potok budowy, 381prace konserwacyjne, 50praktyki BDD, 38problemy, 53proces

budowania, 373rozwoju oprogramowania, 28

programFrequent Flyer, 107, 152, 300Selenium WebDriver, 251

programista, 28

programowaniedziedzinowe, DDD, 37sterowane testami, TDD, 31, 36sterowane testami akceptacyjnymi,

ATDD, 38sterowane zachowaniami, BDD, 23

projektBehave, 208Cucumber-JVM, 202typu silos, 54

przekazywanieparametrów, 187tabel, 205tabel do kroków, 198

przep yw pracy, 239przyciski opcji, 264przypadki u ycia, use cases, 120pseudostrukturalny format, 150publikacje, 53publikowanie dynamicznej dokumentacji,

384, 385

Rraportowanie, 49, 353realne opcje, 140refaktoryzacja, 322rejestr, backlog, 93rezultaty oczekiwane, 238rodzaje rozmów, 147rozk ad jazdy poci gów, 58rozmowy, 147, 290rozszerzenie SpecFlow, 211rozwijane listy, 264

Sscenariusz JBehave, 73scenariusze

automatyzacja, 179automatyzowanie, 182, 194, 207, 211, 216bazuj ce na przyk adach, 191b dy, 200dane specyficzne, 233krok, 201niepowodzenia, 200oczekuj ce, 192opisywanie, 156, 174organizowanie, 171




Skorowidz 403

tagi, 174unikanie zale no ci, 170uruchamianie, 213w opracowaniu, 192wykorzystanie tabel, 160

scenariuszeekspresywne, 165kryteriów akceptacji, 317wykonywalne, 151

SDS, System Design Specification, 48selektory CSS, 258Selenium Grid, 392serwer Selenium Grid, 391serwis GitHub, 66sie kolejowa, 59si a has a, 139s owa kluczowe, 43, 64, 158SOA, Service Oriented Architecture, 299specyfikacja

cech funkcjonalnych, 40niskopoziomowa, 47przez przyk ad, 38samowystarczalna, 375wykonywalna, 45, 67

Spock, 47stan pomi dzy krokami, 188stosowanie praktyk BDD, 53strategia ci g ej integracji, 378, 383strona WWW, 255struktura

„Zak adaj c... Gdy... Wtedy”, 157pakietu, 74projektu Behave, 208projektu Cucumber-JVM, 202

systemBehave, 208Concordion, 367Cucumber-JS, 216ECSS, 25kontroli wersji, 376Selenium Grid, 394

szablon formu y wizji, 98szacowanie godziny przyjazdu, 70

Ttabele, 160

osadzone, 210przyk adów, 206

tablice zada , task boards, 360tag, 171TDD, Test-Driven Development, 31, 35, 76,

311techniczna dynamiczna dokumentacja, 368tematy, themes, 120tester, 28, 180testowanie

aplikacji AJAX, 265getterów i setterów, 322interfejsu u ytkownika, 247logiki biznesowej, 295us ug sieciowych RESTFUL, 300warstwy us ug, 299wymaga niefunkcjonalnych, 304

testyakceptacyjne, 82, 290akceptacyjne u ytkownika, 374automatyczne, 72, 224jako dynamiczna dokumentacja, 81jednostkowe, 48, 76, 309, 336, 369

w JUnit, 329w Spock, 80, 329

nieuwzgl dniaj ce UI, 250NUnit, 342równoleg e, 388webowe, 247, 248

t o, 168tradycyjny proces rozwoju, 28tryb headless, 248tworzenie raportów, 364typy automatycznych testów akceptacji, 290

UUAT, 374UI, user interface, 246, 285uruchamianie scenariuszy, 213, 219

w Behave, 210u ci lanie celów biznesowych, 103uwzgl dnianie niepewno ci, 41u ytkownik, 33u ywanie

plików cech funkcjonalnych, 171p ynnego kodowania, 346testów akceptacji, 286




404 Skorowidz

Wwady, 53warianty wzorców, 200, 204warstwa

przep ywu pracy, 239regu biznesowych, 238techniczna, 241us ug, 299

warstwyabstrakcji, 237interfejsu u ytkownika, 245

warto ci biznesowe, 39warto opcji, 141webowe kryteria akceptacji, 251wiersz polecenia, 377wizja projektu, 95–97w a ciwe budowanie oprogramowania, 30wprowadzenie do BBD, 34wska nik ROI, 114wspó dzielenie danych, 197, 206, 214wstrzykiwanie

cech funkcjonalnych, 89–96funkcji, 91, 92

wygasanie opcji, 143wykonywalne

scenariusze, 150, 151specyfikacje, 42, 149

wykorzystaniedanych tabelarycznych, 190jawnego oczekiwania, 266kodu definicji kroku, 319niejawnego oczekiwania, 266Selenium Grid, 391tabel, 161tagów, 364UI, 285

wymagania, requirements, 87, 120niefunkcjonalne, 304niekorzystaj ce z UI, 283niskopoziomowe, 325wysokopoziomowe, 110

wynikikroków, 207programowania BDD, 39scenariusza, 192

wyra enia XPath, 261wysokopoziomowe

cechy funkcjonalne, 69, 108kryterium akceptacji, 316wymagania, 110, 312

wysokopoziomowy opis cechy, 94wyszukiwanie

warto ci, 93zagnie d one, 263

wzorzec, 200, 204architektury MVC, 291Obiekty stron, 268

Zzadania, tasks, 120zakres projektu, 61zarz dzanie

bazuj ce na celach, 104niepewno ci , 120projektem, 353

zasady BDD, 38zautomatyzowane

kryteria akceptacji, 385, 389testy akceptacyjne, 385

zautomatyzowany proces budowy, 386zdolno , capability, 112, 120, 122zespó piel gnacyjny, BAU, 81zestaw, suite, 375

testów, test suite, 224wysokopoziomowych wymaga , 110

znane encje, 235zobowi zania, 143zrefaktoryzowanie implementacji, 36




http://program-partnerski.helion.pl

Tytuł oryginału: BDD in Action: Behavior-Driven Development for … · 2019-05-15 · Spis tre ci...

Documents

Transcript of Tytuł oryginału: BDD in Action: Behavior-Driven Development for … · 2019-05-15 · Spis tre ci...