reklama - zainteresowany?

BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji - Helion


Autor: John Ferguson Smart
Tytuł oryginału: BDD in Action: Behavior-driven development for the whole software lifecycle
Tłumaczenie: Radosław Meryk
ISBN: 978-83-283-1747-5
stron: 408, Format: 168x237, okładka: miękka
Data wydania: 2016-02-12
Księgarnia: Helion

Cena książki: 23,90 zł (poprzednio: 74,69 zł)
Oszczędzasz: 68% (-50,79 zł)

Dodaj do koszyka

Tagi: .NET - Programowanie | Java - Programowanie | JavaScript - Programowanie

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:

  • teorię i praktykę BDD
  • zasady stosowania BDD w pracy zespołowej
  • testy akceptacyjne, integracyjne i jednostkowe BDD
  • praktyczne przykłady w Javie, .NET, JavaScripcie i innych językach
  • sposoby tworzenia raportów i dynamicznej dokumentacji BDD

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.

Dodaj do koszyka

 

Osoby które kupowały "BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji", wybierały także:

  • ASP.NET MVC 4. Zaawansowane programowanie
  • ASP.NET MVC 4. Programowanie aplikacji webowych
  • ASP.NET MVC 4. Programowanie
  • ASP.NET 3.5. Programowanie

Dodaj do koszyka

Spis treści

BDD w działaniu. Sterowanie zachowaniem w rozwoju aplikacji -- spis treści

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)

Dodaj do koszyka

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2020 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.