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ść
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
3.9. Podsumowanie 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
Poleć książkęKup książkę
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
5.6. Podsumowanie 176
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
Poleć książkęKup książkę
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
6.9. Podsumowanie 220
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
Poleć książkęKup książkę
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
7.4. Podsumowanie 243
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
8.4. Podsumowanie 281
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
Poleć książkęKup książkę
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
10.6. Podsumowanie 349
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
Poleć książkęKup książkę
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
11.7. Podsumowanie 372
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
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 :
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
60 ROZDZIA 2. BDD z lotu ptaka
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 .
Poleć książkęKup książkę
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 ?
Poleć książkęKup książkę
62 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
64 ROZDZIA 2. BDD z lotu ptaka
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?
Poleć książkęKup książkę
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
Poleć książkęKup książkę
66 ROZDZIA 2. BDD z lotu ptaka
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.
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 67
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.
Poleć książkęKup książkę
68 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 69
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
Poleć książkęKup książkę
70 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 71
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
Poleć książkęKup książkę
72 ROZDZIA 2. BDD z lotu ptaka
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 .
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 73
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
Poleć książkęKup książkę
74 ROZDZIA 2. BDD z lotu ptaka
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.
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 75
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
Poleć książkęKup książkę
76 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 77
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.
Poleć książkęKup książkę
78 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
2.4. Implementacja — budowanie i dostarczanie cech funkcjonalnych 79
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.
Poleć książkęKup książkę
80 ROZDZIA 2. BDD z lotu ptaka
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
82 ROZDZIA 2. BDD z lotu ptaka
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.
Poleć książkęKup książkę
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.
Poleć książkęKup książkę
84 ROZDZIA 2. BDD z lotu ptaka
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.
Poleć książkęKup książkę
2.6. Podsumowanie 85
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.
Poleć książkęKup książkę
86 ROZDZIA 2. BDD z lotu ptaka
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę
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
Poleć książkęKup książkę