reklama - zainteresowany?

TDD. Poradnik programisty - Helion

TDD. Poradnik programisty
Autor: Dariusz Woźniak
ISBN: 978-83-283-3531-8
okładka: miękka
Data wydania: 2018-01-01
Księgarnia: Helion

Cena książki: 17,90 zł (poprzednio: 57,74 zł)
Oszczędzasz: 69% (-39,84 zł)

Dodaj do koszyka TDD. Poradnik programisty

Dodaj do koszyka TDD. Poradnik programisty

 

Osoby które kupowały "TDD. Poradnik programisty", wybierały także:

  • Windows Media Center. Domowe centrum rozrywki
  • Ruby on Rails. Ćwiczenia
  • Przywództwo w Å›wiecie VUCA. Jak być skutecznym liderem w niepewnym Å›rodowisku
  • Scrum. O zwinnym zarzÄ…dzaniu projektami. Wydanie II rozszerzone
  • Od hierarchii do turkusu, czyli jak zarzÄ…dzać w XXI wieku

Dodaj do koszyka TDD. Poradnik programisty

Spis treści

TDD. Techniki programowania sterowanego testami -- spis treści

Podziękowania (11)

Przedmowa (13)

Cytaty o TDD (15)

Wstęp (17)

  • Przewodnik po książce (19)
  • Dla kogo jest ta książka? (20)
    • W jakim stopniu muszÄ™ umieć programować? (20)
    • Nie jestem programistÄ… C#. Czy ta książka ma jakÄ…Å› wartość dla mnie? (20)
    • Umiem pisać testy jednostkowe i znam TDD. Czy ta książka jest dla mnie? (21)
    • Jestem menadżerem/dyrektorem/wÅ‚aÅ›cicielem (a wiÄ™c nie programujÄ™), a mój zespóÅ‚ chce wdrożyć TDD. Czy z tej książki dowiem siÄ™, czy warto? (22)
    • Jestem manualnym testerem. Czy powinienem znać TDD? (22)
  • Kontekst jest królem (23)
    • Atrapa to mock czy test double? (23)
    • xUnit a xUnit.net (24)
    • Funkcja a funkcjonalność oraz funkcyjny a funkcjonalny (24)
    • Synonimy (25)
  • Jak uczyć siÄ™ metody Test-Driven Development? (25)
  • Dogmat (26)
  • NarzÄ™dzia użyte w tej książce (27)
  • Kod źródÅ‚owy do książki (28)

Rozdział 1. Wprowadzenie do TDD (29)

  • BÅ‚Ä™dy w oprogramowaniu (31)
  • Cykl Red-Green-Refactor (32)
  • Podsumowanie (33)

Rozdział 2. Co zyskujemy dzięki TDD? (35)

  • Wysoka jakość kodu (35)
    • Czy pisanie w metodyce TDD oznacza pisanie wedÅ‚ug zasad SOLID? (36)
  • Prostota kodu: YAGNI i KISS (37)
  • Å»ywa dokumentacja (38)
  • Lepsze zrozumienie wymagaÅ„ biznesowych (38)
  • Automatyczna regresja (39)
  • Informacja zwrotna (41)
  • Mniej defektów (42)
  • Czas programowania jest krótszy (43)
  • Niższy koszt zmian (43)
  • Przypadki użycia (45)
    • Badanie Microsoft Research nad zespoÅ‚ami Microsoftu i IBM (45)
    • Pilotażowy projekt dla dużej firmy (45)
    • MaÅ‚y projekt w parach (47)
    • Metaanaliza (47)
  • Podsumowanie (48)

Rozdział 3. Trudności przy wdrażaniu TDD (49)

  • Åšcieżka nauki (49)
  • Dyscyplina (50)
  • WiÄ™cej narzÄ™dzi (50)
  • PoczÄ…tkowa percepcja dÅ‚uższego czasu potrzebnego do napisania kodu (51)
  • Jak "sprzedać" TDD kierownictwu? (51)
  • Musimy dostarczać szybko, a w naszym projekcie nie ma czasu na TDD (51)
    • Lista kontrolna: Definition of Done (52)
  • Podsumowanie (56)

Rozdział 4. Filozofia TDD (57)

  • Test-First czy Test-Last? (58)
  • Wszystkie testy naraz czy test po teÅ›cie? (59)
  • Weryfikacja stanu czy zachowania? (60)
  • Jedna czy wiele asercji? (60)
    • Scenariusz 1.: Jedna oczekiwana zmienna wyjÅ›ciowa (60)
    • Scenariusz 2.: Wiele oczekiwanych zmiennych wyjÅ›ciowych (61)
    • Scenariusz 3.: Asercje poÅ›rednie (62)
    • Wiele asercji w jednym teÅ›cie (66)
  • Kiedy pisanie testów jednostkowych nie ma sensu? (67)
  • Czy należy pisać testy jednostkowe do bibliotek innych dostawców? (68)
  • Czy TDD sprawdza siÄ™ dla maÅ‚ych aplikacji? (69)
  • Czy TDD sprawdza siÄ™ dla dużych aplikacji? (70)
  • Czy testy jednostkowe zastÄ™pujÄ… testera? (70)
  • Jak pisanie testów jednostkowych wpÅ‚ywa na estymatÄ™ zadania? (71)
  • Czy testy jednostkowe można pisać w innym jÄ™zyku programowania niż pisany jest kod? (71)
  • Czy testy jednostkowe może pisać inna osoba? (72)
  • Czy system może mieć zbyt dużo testów jednostkowych? (72)
  • Czy testy jednostkowe to jedyne testy, jakie powinny znajdować siÄ™ w aplikacji? (73)
  • Jakich testów powinno być najwiÄ™cej (piramida testów)? (74)
  • Podsumowanie (75)

RozdziaÅ‚ 5. Rodzaje testów (77)

  • Sposób wykonywania (77)
  • Wiedza na temat struktury systemu (test skrzynki) (77)
  • Poziom testowania (78)
  • Testowanie po zmianach dokonanych w systemie (80)
  • Testowanie niefunkcjonalne (80)
    • Test wydajnoÅ›ciowy (81)
  • Podsumowanie (82)

Rozdział 6. Test jednostkowy (83)

  • Struktura testu: Arrange-Act-Assert (83)
    • Alternatywne struktury testu (84)
  • Test jednostkowy a test integracyjny (85)
  • MyÅ›l jak tester: Å›cieżki optymistyczne i przypadki brzegowe (86)
  • Jak nazywać klasy i metody testowe? (87)
  • PodziaÅ‚ testów i projekty testowe (88)
  • Podsumowanie (89)

Rozdział 7. Nasz pierwszy test jednostkowy (91)

  • Wybór biblioteki do testowania (91)
  • Zanim zaczniemy... (92)
    • Dodanie solucji i projektów (92)
    • Dodanie biblioteki NUnit (93)
  • Etap red: pisanie testu do nieistniejÄ…cej metody (95)
    • Jak uruchomić test? (98)
  • Etap green: implementacja kodu (102)
  • Etap trzeci (i ostatni): refaktoryzacja kodu (103)
  • Podsumowanie (103)

Rozdział 8. Piszemy kolejne testy jednostkowe (105)

  • Drugi test jednostkowy (105)
  • Kolejne przypadki użycia (106)
    • Testy uÅ‚amków nieskoÅ„czonych lub zaokrÄ…glonych (108)
  • Testowanie wyrzucenia wyjÄ…tku (109)
  • Testowanie zdarzenia (111)
  • Podsumowanie (114)

Rozdział 9. Testowanie z NUnitem (115)

  • Asercje (116)
    • Model klasyczny i model oparty na twierdzeniach (118)
  • Operacja równoÅ›ci (120)
    • Porównanie dwóch typów wartoÅ›ciowych (121)
    • Porównanie dwóch typów referencyjnych (122)
    • Porównanie dwóch typów referencyjnych z nadpisanym operatorem porównania (122)
    • Tolerancja: delta i procent (124)
    • Tolerancja: czas (124)
    • WÅ‚asna klasa obsÅ‚ugujÄ…ca porównanie (125)
    • Metody pomocnicze (126)
  • Operacje porównania (126)
    • WÅ‚asna klasa obsÅ‚ugujÄ…ca porównanie (127)
    • Należy do zakresu (128)
  • ZÅ‚ożenia (128)
  • Testowanie typów (129)
  • Testowanie wyjÄ…tków (131)
    • Testowanie, czy kod wyrzuciÅ‚ wyjÄ…tek (133)
    • Testowanie, czy kod nie wyrzuciÅ‚ wyjÄ…tku (135)
    • Testowanie parametru i komunikatu wyjÄ…tku (136)
    • Testowanie wewnÄ™trznego wyjÄ…tku (137)
  • Typ tekstowy (137)
  • Kolekcje (138)
  • System plików (141)
  • Komunikaty (142)
    • WÅ‚asne komunikaty bÅ‚Ä™dów (144)
    • WÅ‚asne komunikaty informacyjne (145)
    • Komunikat a nazwa testu (146)
  • WspóÅ‚dzielenie danych (147)
    • Kiedy korzystać ze wspóÅ‚dzielenia danych? (148)
  • Testy parametryzowane (150)
    • TestCase (151)
    • Values (152)
    • Range (154)
    • Random (154)
    • TestCaseSource (155)
    • ValueSource (160)
    • Testy oparte na zewnÄ™trznych źródÅ‚ach (160)
  • Strategie Å‚Ä…czenia wartoÅ›ci testowych (161)
    • Test kombinatoryczny (161)
    • Test sekwencyjny (162)
    • Test par (163)
  • Teorie (166)
  • Testowanie klas generycznych (170)
    • Zasada podstawienia Liskov (172)
  • Testowanie wywoÅ‚aÅ„ asynchronicznych (174)
  • RównolegÅ‚e uruchamianie testów (178)
    • Poziom zrównoleglenia (179)
    • Kiedy zrównoleglić uruchamianie testów? (179)
  • PozostaÅ‚e atrybuty (179)
    • Sterowanie wÄ…tkiem (180)
    • Kategoria testu (180)
    • Atrybuty informacyjne (182)
    • Przekazywanie parametrów (182)
    • Ignorowanie testów (183)
    • Kolejność wykonywania testów (185)
    • Ustawienia regionalne (185)
    • Powtarzanie testu (188)
    • Czas wykonywania testu (189)
    • Platforma (190)
    • Atrybuty a testy parametryzowane (192)
  • Podsumowanie (192)

RozdziaÅ‚ 10. Testowanie zależnoÅ›ci i atrapy obiektów (193)

  • RÄ™czne tworzenie atrapy (195)
    • Kryterium akceptacji nr 1: wiek klienta niższy niż 18 lat (196)
    • Kryterium akceptacji nr 2: wiek klienta wiÄ™kszy bÄ…dź równy 18 lat (198)
    • Kryterium akceptacji nr 3: jeÅ›li obiekt klienta jest nullem, to wyrzuć wyjÄ…tek (200)
    • Podsumowanie (200)
  • Wprowadzenie do frameworku Moq (201)
  • SkÅ‚adnia imperatywna i deklaratywna (202)
    • SkÅ‚adnia imperatywna (203)
    • SkÅ‚adnia deklaratywna (204)
    • Wybór skÅ‚adni (205)
  • Atrapa rekursywna (recursive mock) (205)
  • Tryb zachowania wÅ‚aÅ›ciwoÅ›ci (stubbing) (206)
  • Zwracanie domyÅ›lnej wartoÅ›ci (207)
  • Atrapa z sekwencyjnym rezultatem (208)
  • Tryb zachowania atrapy (MockBehavior) (209)
  • Przekazywanie parametrów w metodzie (argument matchers) (210)
    • Ponowne użycie matcherów (215)
  • Weryfikacja wywoÅ‚aÅ„ (216)
    • Weryfikacja wywoÅ‚ania metody (217)
    • Weryfikacja dostÄ™pu i zapisu wÅ‚aÅ›ciwoÅ›ci (219)
    • Testować stan czy zachowanie? (220)
    • Komunikat bÅ‚Ä™du (221)
    • Podsumowanie (222)
  • WywoÅ‚anie zwrotne: Callback (222)
    • Podsumowanie (224)
  • WywoÅ‚anie skÅ‚adowej bazowej: CallBase (224)
  • Atrapa wyrzucajÄ…ca wyjÄ…tek (226)
  • Inne poziomy dostÄ™pnoÅ›ci (227)
    • protected (228)
    • internal (229)
    • Podsumowanie (229)
  • Klasyfikacja atrap (230)
    • Dummy (230)
    • Stub (232)
    • Fake (233)
    • Mock (235)
    • Spy (235)
    • Podsumowanie (236)
  • Ograniczenia Moqa (237)
  • Tworzenie atrap dla klas i metod statycznych (238)
  • Rodzaje bibliotek do tworzenia atrap (241)
    • Constrained (241)
    • Unconstrained (241)
    • Constrained czy unconstrained? (242)
  • Podsumowanie (243)

RozdziaÅ‚ 11. Dobre praktyki pisania testów jednostkowych (245)

  • Test powinien być szybki, bardzo szybki! (246)
  • Testy powinny być odizolowane i niezależne od siebie (247)
  • Test powinien być powtarzalny (247)
  • Test powinien być deterministyczny (248)
  • Test nie powinien mieć zależnoÅ›ci zewnÄ™trznych (248)
  • Test nie powinien mieć konfiguracji (249)
  • Wynik testu nie powinien być interpretowany (249)
  • Test nie powinien być pusty (250)
  • Zalążek kodu powinien wyrzucać wyjÄ…tek (250)
  • Test powinien mieć jednÄ… logicznÄ… asercjÄ™ (251)
  • Testy nie powinny być dyskryminowane (251)
  • Testy powinny być podzielone wedÅ‚ug kategorii (251)
  • Test powinien mieć strukturÄ™ Arrange-Act-Assert (251)
  • Test powinien obejmować Å›cieżki optymistyczne i przypadki brzegowe (252)
  • Test powinien mieć odpowiedniÄ… nazwÄ™ (252)
  • Testowane powinny być tylko publiczne skÅ‚adowe (252)
  • Test powinien oczekiwać konkretnego typu wyjÄ…tku (253)
  • Test powinien oczekiwać wyjÄ…tku w konkretnym wyrażeniu (253)
  • Test nie powinien zawierać instrukcji warunkowych i pÄ™tli (253)
  • Test powinien mieć wartoÅ›ci oczekiwane wpisane "na sztywno" (254)
  • Test powinien mieć asercjÄ™ (255)
  • Test powinien być nieskomplikowany (255)
  • Test nie powinien być "przespecyfikowany" (256)
  • Test nie powinien zawierać metod z atrybutami SetUp i TearDown (257)
  • Klasa testowa powinna być bezstanowa (257)
  • Komunikaty asercji nie powinny być nadmiarowe (258)
  • Podsumowanie (259)

Rozdział 12. TDD i istniejący kod (261)

  • Refaktoryzacja bezpieczna i mniej bezpieczna (261)
    • PrzykÅ‚ad bezpiecznej refaktoryzacji (264)
  • Dodawanie testów do istniejÄ…cego kodu (271)
    • Gdzie zacząć dodawać testy? (271)
    • Jak pisać testy? (272)
    • NarzÄ™dzia (274)
  • Podsumowanie (275)

Rozdział 13. Pokrycie kodu testami (277)

  • Co to jest pokrycie kodu testami? (277)
  • NarzÄ™dzia do mierzenia pokrycia kodu (278)
  • W ile procent pokrycia powinniÅ›my celować? (281)
    • PrzykÅ‚ady "faÅ‚szywych" testów o stuprocentowym pokryciu kodu (281)
  • Podsumowanie (283)
    • 85%, 90% czy 100%? (283)
    • Pokrycie kodu jako narzÄ™dzie do identyfikowania brakujÄ…cych testów (284)

Rozdział 14. Ciągła integracja (285)

  • Serwer ciÄ…gÅ‚ej integracji (286)
  • CiÄ…gÅ‚a dostawa i ciÄ…gÅ‚e wdrażanie (288)
  • Podsumowanie (289)

Dodatek A. Biblioteki do testowania (291)

Dodatek B. Biblioteki do tworzenia atrap (293)

Dodatek C. Biblioteki do mierzenia pokrycia kodu testami (297)

Dodatek D. Testy z danymi zewnętrznymi - przypadek użycia (299)

Dodatek E. Rozszerzalność NUnita (303)

  • Atrybut informacyjny (305)
  • Atrybut umożliwiajÄ…cy wspóÅ‚dzielenie danych (307)

Dodatek F. Bibliografia (311)

  • ŹródÅ‚a internetowe (314)

Skorowidz (319)

Dodaj do koszyka TDD. Poradnik programisty

Code, Publish & WebDesing by CATALIST.com.pl



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