Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00498 014126 11055617 na godz. na dobę w sumie
BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji - ebook/pdf
BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji - ebook/pdf
Autor: Liczba stron: 408
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-1750-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> webmasterstwo >> javascript - programowanie
Porównaj ceny (książka, ebook (-20%), audiobook).
Rozwój technik BDD jest odpowiedzią na poważny problem, z którym muszą się zmierzyć zespoły rozwijające oprogramowanie. Tym problemem jest skuteczne komunikowanie i zrozumienie się nawzajem. Jeśli jesteś kierownikiem projektu, musisz jakoś skłonić programistę do pisania testów, namówić testera do zaakceptowania tych testów i przekonać inwestora, że coś, co nie jest kodem produkcyjnym, może mieć swoją wartość. Okazuje się, że kluczem do sukcesu jest doprowadzenie do sytuacji, w której każdy rozumie, do czego ma służyć aplikacja, jak się ma zachować i jakie są jej kluczowe funkcje. Świetnym narzędziem ułatwiającym taką pracę jest technika BDD — obszerny zbiór najlepszych praktyk i narzędzi wspomagających analizę wymagań i automatyzację testów.

Książka, którą trzymasz w dłoni, stanowi przegląd praktyk BDD na wszystkich poziomach procesu rozwoju oprogramowania. Znajdziesz w niej informacje na temat odkrywania i określania wysokopoziomowych wymagań, implementacji funkcji aplikacji oraz pisania automatycznych testów akceptacyjnych i jednostkowych. Jest ona niezastąpionym przewodnikiem dla analityków biznesowych i deweloperów, testerów, a przede wszystkim liderów i menedżerów projektów.

Dzięki tej książce poznasz:

Już dziś przedstaw swojemu zespołowi rewolucyjne techniki BDD!

John Ferguson Smart — światowej klasy specjalista w dziedzinie BDD, automatycznego testowania i optymalizacji rozwoju oprogramowania w całym cyklu życia, umiejętnie łączący wiedzę programisty i zalety coacha.

 
Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

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

Gdzie kupić całą publikację:

BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: