BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji John Ferguson Smart

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

Słowo wstępne (11)

Przedmowa (15)

Podziękowania (17)

O tej książce (19)

CZĘŚĆ I. PIERWSZE KROKI (23)

Rozdział 1. Budowanie oprogramowania, które sprawia różnicę (25)

• 1.1. BDD z wysokości 15 kilometrów (27)
• 1.2. Jakie problemy próbujemy rozwiązywać? (29)
  
  • 1.2.1. Właściwe budowanie oprogramowania (30)
  • 1.2.2. Budowanie właściwego oprogramowania (32)
  • 1.2.3. Ograniczenia wiedzy - radzenie sobie z informacją niepewną (32)
• 1.3. Wprowadzenie do programowania sterowanego zachowaniami (34)
  
  • 1.3.1. BDD pierwotnie zaprojektowano jako ulepszoną wersję TDD (35)
  • 1.3.2. Techniki BDD również sprawdzają się jako narzędzia analizy wymagań (37)
  • 1.3.3. Zasady i praktyki BDD (38)
• 1.4. Korzyści z BDD (52)
  
  • 1.4.1. Mniejsze marnotrawstwo (52)
  • 1.4.2. Niższe koszty (52)
  • 1.4.3. Łatwiejsze i bezpieczniejsze zmiany (53)
  • 1.4.4. Szybsze publikacje (53)
• 1.5. Wady i potencjalne problemy związane ze stosowaniem praktyk BDD (53)
  
  • 1.5.1. Stosowanie praktyk BDD wymaga dużego zaangażowania i współpracy (53)
  • 1.5.2. Praktyki BDD sprawdzają się najlepiej w kontekście metodologii Agile lub innej metodologii iteracyjnej (53)
  • 1.5.3. Praktyki BDD nie sprawdzają się dobrze w projektach typu silos (54)
  • 1.5.4. Źle napisane testy mogą prowadzić do wyższych kosztów utrzymania (54)
• 1.6. Podsumowanie (54)

Rozdział 2. BDD z lotu ptaka (57)

• 2.1. Wprowadzenie w tematykę aplikacji rozkładu jazdy pociągów (58)
• 2.2. Określenie korzyści ze stosowania proponowanej aplikacji (60)
• 2.3. Analiza wymagań - odkrywanie i zrozumienie funkcji (60)
  
  • 2.3.1. Opisywanie funkcji (60)
  • 2.3.2. Podział cech funkcjonalnych na historyjki (62)
  • 2.3.3. Ilustrowanie historyjek przykładami (63)
• 2.4. Implementacja - budowanie i dostarczanie cech funkcjonalnych (64)
  
  • 2.4.1. Od przykładów do kryteriów akceptacji (64)
  • 2.4.2. Konfigurowanie narzędzi Maven i Git (65)
  • 2.4.3. Specyfikacje wykonywalne - automatyzacja kryteriów akceptacji (67)
  • 2.4.4. Automatyczne testy - implementacja kryteriów akceptacji (72)
  • 2.4.5. Testy jako dynamiczna dokumentacja (81)
• 2.5. Utrzymanie (81)
• 2.6. Podsumowanie (85)

CZĘŚĆ II. CZEGO CHCĘ? DEFINIOWANIE WYMAGAŃ Z WYKORZYSTANIEM BDD (87)

Rozdział 3. Zrozumieć cele biznesowe. Wstrzykiwanie cech funkcjonalnych i związane z tym techniki (89)

• 3.1. Poznajemy firmę Flying High (91)
• 3.2. Wstrzykiwanie funkcji (92)
  
  • 3.2.1. Wyszukiwanie wartości (93)
  • 3.2.2. Wstrzykiwanie cech funkcjonalnych (93)
  • 3.2.3. Wskazanie przykładów (94)
  • 3.2.4. Podsumowanie (94)
• 3.3. Co chcesz osiągnąć? Zacznij od wizji (96)
  
  • 3.3.1. Formuła wizji (97)
  • 3.3.2. Korzystanie z szablonów formuły wizji (98)
• 3.4. W jaki sposób firma skorzysta na projekcie? Identyfikowanie celów biznesowych (99)
  
  • 3.4.1. Pisanie dobrych celów biznesowych (100)
  • 3.4.2. Pokaż mi pieniądze - cele biznesowe a przychody (101)
  • 3.4.3. Ściąganie ze "stosu dlaczego" - uściślanie celów biznesowych (103)
• 3.5. Mapowanie wpływu - podejście wizualne (106)
• 3.6. Kto na tym skorzysta? Identyfikowanie interesariuszy i ich potrzeb (110)
• 3.7. Co trzeba zbudować? Identyfikowanie zdolności (112)
• 3.8. Jakie cechy funkcjonalne zapewnią największy wskaźnik ROI? Model dopasowania do celów (114)
  
  • 3.8.1. Cechy wyróżniające (116)
  • 3.8.2. Cechy równoważne (116)
  • 3.8.3. Cechy partnerskie (117)
  • 3.8.4. Cechy o minimalnym wpływie (117)
• 3.9. Podsumowanie (117)

Rozdział 4. Definiowanie i ilustrowanie cech funkcjonalnych (119)

• 4.1. Co to jest cecha funkcjonalna? (120)
  
  • 4.1.1. Cechy funkcjonalne dostarczają zdolności (122)
  • 4.1.2. Cechy funkcjonalne można podzielić na łatwiejsze do zarządzania fragmenty (126)
  • 4.1.3. Cecha funkcjonalna może być opisana za pomocą jednej lub kilku historyjek użytkowników (128)
  • 4.1.4. Cecha funkcjonalna nie jest historyjką użytkownika (131)
  • 4.1.5. Eposy to naprawdę duże historyjki użytkownika (132)
  • 4.1.6. Nie wszystko pasuje do hierarchii (133)
• 4.2. Ilustrowanie cech funkcjonalnych przykładami (134)
• 4.3. Realne opcje - podejmuj zobowiązania dopiero wtedy, kiedy musisz (140)
  
  • 4.3.1. Opcje mają wartość (141)
  • 4.3.2. Opcje wygasają (143)
  • 4.3.3. Nigdy nie zobowiązuj się zbyt wcześnie, jeśli nie wiesz dlaczego (143)
• 4.4. Celowe odkrywanie (144)
• 4.5. Od przykładów do działającego oprogramowania - szerszy obraz (145)
• 4.6. Podsumowanie (146)

Rozdział 5. Od przykładów do wykonywalnych specyfikacji (149)

• 5.1. Przekształcanie konkretnych przykładów na wykonywalne scenariusze (151)
• 5.2. Pisanie wykonywalnych scenariuszy (154)
  
  • 5.2.1. Plik cech funkcjonalnych zawiera tytuł i opis (154)
  • 5.2.2. Opisywanie scenariuszy (156)
  • 5.2.3. Struktura "Zakładając... Gdy... Wtedy" (157)
  • 5.2.4. Uzupełniające słowa kluczowe (158)
  • 5.2.5. Komentarze (159)
• 5.3. Wykorzystanie tabel w scenariuszach (160)
  
  • 5.3.1. Używanie tabel w pojedynczych krokach (160)
  • 5.3.2. Wykorzystanie tabel przykładów (161)
• 5.4. Scenariusze ekspresywne - wzorce i antywzorce (165)
  
  • 5.4.1. Pisanie ekspresywnych kroków Zakładając (165)
  • 5.4.2. Pisanie ekspresywnych kroków Gdy (166)
  • 5.4.3. Pisanie ekspresywnych kroków Wtedy (167)
  • 5.4.4. Podawanie tła i kontekstu (168)
  • 5.4.5. Unikanie zależności między scenariuszami (170)
• 5.5. Organizowanie scenariuszy przy użyciu plików cech funkcjonalnych i tagów (171)
  
  • 5.5.1. Scenariusze zapisuje się w plikach opisu cech funkcjonalnych (172)
  • 5.5.2. Plik opisu cechy funkcjonalnej może zawierać jeden lub więcej scenariuszy (172)
  • 5.5.3. Organizowanie plików opisu cech funkcjonalnych (173)
  • 5.5.4. Opisywanie scenariuszy za pomocą tagów (174)
• 5.6. Podsumowanie (176)

Rozdział 6. Automatyzacja scenariuszy (179)

• 6.1. Wprowadzenie do automatyzowania scenariuszy (182)
  
  • 6.1.1. Definicje kroków interpretują tekst scenariuszy (182)
  • 6.1.2. Zachowaj prostotę metod definicji kroków (184)
• 6.2. Implementacja definicji kroków - zasady ogólne (186)
  
  • 6.2.1. Instalowanie narzędzi BDD (186)
  • 6.2.2. Implementacja definicji kroków (187)
  • 6.2.3. Przekazywanie parametrów do implementacji kroków (187)
  • 6.2.4. Utrzymywanie stanu pomiędzy krokami (188)
  • 6.2.5. Wykorzystywanie danych tabelarycznych z definicji kroków (190)
  • 6.2.6. Implementacja scenariuszy bazujących na przykładach (191)
  • 6.2.7. Wyniki scenariusza (192)
• 6.3. Bardziej efektywna implementacja BDD z wykorzystaniem narzędzia Thucydides (193)
• 6.4. Automatyzowanie scenariuszy w Javie z wykorzystaniem JBehave (194)
  
  • 6.4.1. Instalowanie i konfigurowanie narzędzia JBehave (194)
  • 6.4.2. Definicje kroków JBehave (195)
  • 6.4.3. Współdzielenie danych pomiędzy krokami (197)
  • 6.4.4. Przekazywanie tabel do kroków (198)
  • 6.4.5. Definicje kroków dla tabel przykładów (199)
  • 6.4.6. Warianty wzorców (200)
  • 6.4.7. Niepowodzenia i błędy w wynikach scenariuszy (200)
• 6.5. Automatyzowanie scenariuszy w Javie przy użyciu narzędzia Cucumber-JVM (202)
  
  • 6.5.1. Konfiguracja i struktura projektu Cucumber-JVM (202)
  • 6.5.2. Definicje kroków Cucumber-JVM (203)
  • 6.5.3. Warianty wzorców (204)
  • 6.5.4. Przekazywanie tabel do definicji kroków (205)
  • 6.5.5. Definicje kroków dla tabel przykładów (206)
  • 6.5.6. Współdzielenie danych pomiędzy krokami (206)
  • 6.5.7. Kroki oczekujące i wyniki kroków (207)
• 6.6. Automatyzowanie scenariuszy w Pythonie z wykorzystaniem Behave (207)
  
  • 6.6.1. Instalacja systemu Behave (208)
  • 6.6.2. Struktura projektu Behave (208)
  • 6.6.3. Definicje kroków Behave (209)
  • 6.6.4. Łączenie kroków (209)
  • 6.6.5. Definicje kroków z wykorzystaniem osadzonych tabel (210)
  • 6.6.6. Definicje kroków dla tabel przykładów (210)
  • 6.6.7. Uruchamianie scenariuszy w Behave (210)
• 6.7. Automatyzowanie scenariuszy w .NET z wykorzystaniem SpecFlow (211)
  
  • 6.7.1. Konfigurowanie SpecFlow (211)
  • 6.7.2. Dodawanie plików opisu cech funkcjonalnych (211)
  • 6.7.3. Uruchamianie scenariuszy (213)
  • 6.7.4. Definicje kroków w SpecFlow (213)
  • 6.7.5. Współdzielenie danych pomiędzy krokami (214)
  • 6.7.6. Definicje kroków z wykorzystaniem tabel przykładów (215)
• 6.8. Automatyzowanie scenariuszy w JavaScript z wykorzystaniem systemu Cucumber-JS (216)
  
  • 6.8.1. Konfigurowanie systemu Cucumber-JS (216)
  • 6.8.2. Pisanie plików opisu funkcji w Cucumber-JS (217)
  • 6.8.3. Implementowanie kroków (218)
  • 6.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 automatycznych testów akceptacyjnych (223)

• 7.1. Pisanie niezawodnych testów akceptacji (225)
• 7.2. Automatyzowanie procesu konfiguracji testu (228)
  
  • 7.2.1. Inicjowanie bazy danych przed każdym testem (228)
  • 7.2.2. Inicjowanie bazy danych na początku zestawu testów (229)
  • 7.2.3. Korzystanie z haków inicjalizacji (229)
  • 7.2.4. Konfigurowanie danych specyficznych dla scenariusza (233)
  • 7.2.5. Użycie person i znanych encji (235)
• 7.3. Oddzielenie warstwy "co" od warstwy "jak" (237)
  
  • 7.3.1. Warstwa reguł biznesowych opisuje oczekiwane rezultaty (238)
  • 7.3.2. Warstwa przepływu pracy opisuje działania użytkownika (239)
  • 7.3.3. Warstwa techniczna realizuje interakcje z systemem (241)
  • 7.3.4. Ile warstw? (242)
• 7.4. Podsumowanie (243)

Rozdział 8. Automatyzacja kryteriów akceptacji dla warstwy interfejsu użytkownika (245)

• 8.1. Kiedy i jak należy testować interfejs użytkownika? (247)
  
  • 8.1.1. Zagrożenie zbyt wieloma testami webowymi (247)
  • 8.1.2. Testy webowe z przeglądarkami w trybie headless (248)
  • 8.1.3. Ile testów webowych naprawdę potrzebujemy? (250)
• 8.2. Automatyzowanie webowych kryteriów akceptacji z wykorzystaniem programu Selenium WebDriver (251)
  
  • 8.2.1. Pierwsze kroki z WebDriver w Javie (252)
  • 8.2.2. Identyfikacja elementów strony WWW (255)
  • 8.2.3. Interakcje z elementami stron WWW (263)
  • 8.2.4. Praca ze stronami asynchronicznymi i testowanie aplikacji AJAX (265)
  • 8.2.5. Pisanie aplikacji webowych "przyjaznych dla testów" (267)
• 8.3. Korzystanie z obiektów stron w celu poprawy czytelności testów (267)
  
  • 8.3.1. Wprowadzenie do wzorca Obiekty stron (268)
  • 8.3.2. Pisanie dobrze zaprojektowanych obiektów stron (273)
  • 8.3.3. Korzystanie z bibliotek rozszerzających bibliotekę WebDriver (279)
• 8.4. Podsumowanie (281)

Rozdział 9. Automatyzacja kryteriów akceptacji dla wymagań niekorzystających z UI (283)

• 9.1. Równowaga pomiędzy testami akceptacyjnymi z wykorzystaniem UI i bez UI (285)
• 9.2. Kiedy używać testów akceptacji bez pośrednictwa UI (286)
• 9.3. Typy automatycznych testów akceptacji niekorzystających z UI (290)
  
  • 9.3.1. Testowanie z wykorzystaniem warstwy kontrolera (291)
  • 9.3.2. Bezpośrednie testowanie logiki biznesowej (295)
  • 9.3.3. Testowanie warstwy usług (299)
• 9.4. Definiowanie i testowanie wymagań niefunkcjonalnych (304)
• 9.5. Odkrywanie projektu (306)
• 9.6. Podsumowanie (308)

Rozdział 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ędzia BDD do testów jednostkowych (313)
• 10.2. Od kryteriów akceptacji do zaimplementowanych cech funkcjonalnych (313)
  
  • 10.2.1. BDD sprzyja stosowaniu podejścia "z zewnątrz do wewnątrz" (314)
  • 10.2.2. Zaczynamy od wysokopoziomowego kryterium akceptacji (316)
  • 10.2.3. Automatyzacja scenariuszy kryteriów akceptacji (317)
  • 10.2.4. Implementacja definicji kroków (317)
  • 10.2.5. Zrozumienie modelu domeny (318)
  • 10.2.6. Pisanie kodu, który chcielibyśmy mieć (319)
  • 10.2.7. Wykorzystanie kodu definicji kroku do wyspecyfikowania i zaimplementowania kodu aplikacji (319)
  • 10.2.8. W jaki sposób stosowanie praktyk BDD pomogło? (324)
• 10.3. Analiza niskopoziomowych wymagań, odkrywanie projektu i implementacja bardziej złożonych funkcjonalności (325)
  
  • 10.3.1. Wykorzystanie kodu definicji kroku do analizy niskopoziomowego projektu (326)
  • 10.3.2. Praca z tabelami przykładów (328)
  • 10.3.3. Odkrywanie nowych klas i usług w miarę 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łożonego kodu (332)
  • 10.3.7. Rozwijanie niskopoziomowych specyfikacji technicznych (333)
• 10.4. Narzędzia, dzięki którym testy jednostkowe BDD stają się łatwiejsze (336)
  
  • 10.4.1. Stosowanie praktyk BDD z tradycyjnymi narzędziami testów jednostkowych (336)
  • 10.4.2. Pisanie specyfikacji, a nie testów - rodzina RSpec (339)
  • 10.4.3. Pisanie bardziej ekspresywnych specyfikacji z wykorzystaniem narzędzi Spock albo Spec2 (343)
• 10.5. Używanie wykonywalnych specyfikacji jako dynamicznej dokumentacji (345)
  
  • 10.5.1. Używanie płynnego kodowania w celu poprawy czytelności (346)
  • 10.5.2. Płynne asercje w języku JavaScript (347)
  • 10.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ądzanie projektem (353)

• 11.1. Dynamiczna dokumentacja - widok wysokopoziomowy (354)
• 11.2. Czy osiągnęliśmy cel? Raporty dotyczące gotowości i pokrycia cech funkcjonalnych (356)
  
  • 11.2.1. Gotowość cech funkcjonalnych - jakie cechy są gotowe do dostarczenia (356)
  • 11.2.2. Pokrycie cechy funkcjonalnej - jakie wymagania zostały spełnione (357)
• 11.3. Integracja z cyfrowym rejestrem projektu (360)
• 11.4. Organizowanie dynamicznej dokumentacji (362)
  
  • 11.4.1. Organizowanie dynamicznej dokumentacji według wysokopoziomowych wymagań (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ź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ł 12. BDD w procesie budowania (373)

• 12.1. Wykonywalne specyfikacje powinny być częścią automatycznego procesu budowy (374)
  
  • 12.1.1. Każda specyfikacja powinna być samowystarczalna (375)
  • 12.1.2. Wykonywalne specyfikacje powinny być przechowywane w systemie kontroli wersji (376)
  • 12.1.3. Powinna istnieć możliwość uruchomienia wykonywalnych specyfikacji z wiersza polecenia (377)
• 12.2. Ciągła integracja przyspiesza cykl sprzężenia zwrotnego (378)
• 12.3. Ciągłe dostawy - każda kompilacja jest potencjalną wersją do opublikowania (380)
• 12.4. Strategia ciągłej integracji w celu wdrażania dynamicznej dokumentacji (383)
  
  • 12.4.1. Publikowanie dynamicznej dokumentacji na serwerze kompilacji (384)
  • 12.4.2. Publikowanie dynamicznej dokumentacji na dedykowanym serwerze WWW (385)
• 12.5. Szybsze zautomatyzowane kryteria akceptacji (385)
  
  • 12.5.1. Uruchamianie równoległych testów akceptacyjnych w obrębie zautomatyzowanego procesu budowy (386)
  • 12.5.2. Uruchamianie równoległych testów na wielu maszynach (388)
  • 12.5.3. Uruchamianie równoległych testów webowych z wykorzystaniem Selenium Grid (391)
• 12.6. Podsumowanie (395)
• 12.7. Ostatnie słowa (396)

Skorowidz (399)

pokaż cały spis treści

ukryj recenzje