Dlaczego potrzebujemy TDD? Pisanie złego kodu Rozpoznawanie złego kodu Złe nazwy zmiennych Złe nazwy funkcji, metod i klas Struktury podatne na błędy Zależność i spójność Obniżenie wydajności zespołu Pogorszenie wyników biznesowych TDD w służbie dobrego kodu Projektowanie wysokiej jakości kodu Zajmuj się szczegółami w prywatnych blokach kodu Wykrywanie wad projektowych Analiza korzyści z pisania testów przed kodem produkcyjnym Zapobieganie błędom w logice Zabezpieczanie się przed przyszłymi defektami Dokumentowanie kodu Obalamy mity na temat TDD „Pisanie testów mnie spowalnia” Zrozumienie korzyści ze spowolnienia Przełamywanie zarzutów dotyczących spowolnienia wynikającego z testów „Testy nie zapobiegają wszystkim błędom” Dlaczego ludzie twierdzą, że testy nie wychwytują wszystkich błędów? Przełamywanie zarzutów, że testy nie wychwytują wszystkich błędów Rozumienie obaw dotyczących pisania złych testów Dla pewności testujemy testy „TDD to gwarancja dobrego kodu” Zrozumienie problemu nadmiernych oczekiwań Zarządzanie oczekiwaniami względem TDD „Kod jest zbyt skomplikowany, aby go testować” Rozumienie przyczyn nietestowalnego kodu Nowe podejście do związku między dobrym projektem a prostymi testami Radzenie sobie z odziedziczonym kodem pozbawionym testów „Przed napisaniem kodu nie wiadomo, co testować” Rozumienie trudności związanych z rozpoczynaniem pracy od pisania testów Co zrobić, żeby nie musieć pisać kodu produkcyjnego na początku? Tworzymy aplikację z użyciem TDD Przygotowanie środowiska programistycznego Instalowanie programu IntelliJ Konfiguracja projektu i bibliotek Omówienie aplikacji Wordz Zasady gry Wordz Poznanie metodyk zwinnych Czytamy historyjki użytkowników — elementy składowe planowania Łączymy programowanie zwinne i TDD Piszemy pierwszy test Początek pracy z TDD — wzorzec przygotowania, działania i asercji Poznajemy strukturę testu Zaczynamy pracę od rezultatów Podniesienie wydajności pracy Cechy dobrego testu Stosowanie zasad FIRST Używamy jednej asercji na test Decydujemy o zakresie testu jednostkowego Wykrywanie częstych błędów Sprawdzanie wyjątków Testujemy tylko metody publiczne Zachowanie hermetyzacji Uczenie się na podstawie testów Chaotyczne przygotowania wywołanie asercje Ograniczenia testów jednostkowych Pokrycie kodu — często bezużyteczny wskaźnik Pisanie złych testów Rozpoczęcie pracy nad aplikacją Wordz Rytm pracy w TDD Stosowanie cyklu czerwone, zielone i refaktoryzacja Prostota nade wszystko — przejście do etapu zielonego Refaktoryzacja do czystego kodu Piszemy kolejne testy do gry Wordz TDD i SOLID wspierają projektowanie Testowe i pozatestowe wsparcie w projektowaniu Zasada jednej odpowiedzialności — proste elementy składowe Zbyt wiele odpowiedzialności sprawia, że z kodem trudniej się pracuje Możliwość ponownego użycia kodu Prostsze utrzymanie w przyszłości Przykład kodu nieprzestrzegającego zasady jednej odpowiedzialności Zastosowanie zasady jednej odpowiedzialności do uproszczenia utrzymania kodu w przyszłości Organizacja testów o jednej odpowiedzialności Zasada odwrócenia zależności — ukrywanie nieistotnych szczegółów Zastosowanie odwrócenia zależności do kodu rysującego kształty Zasada podstawienia Liskov — wymienne obiekty Aplikujemy zasadę podstawienia Liskov do kodu rysującego kształty Zasada otwarte-zamknięte — rozszerzalny projekt Dodajemy nowy typ kształtu Zasada segregacji interfejsów — skuteczne abstrakcje Przegląd użycia zasady segregacji interfejsów w kodzie

Zamienniki testowe — zaślepki i atrapy Problemy z obiektami pomocniczymi w testach Wyzwanie testowania niepowtarzalnych zachowań Wyzwanie testowania obsługi błędów Przyczyny trudności w testowaniu Cel stosowania zamienników testowych Piszemy wersję produkcyjną kodu Używanie zaślepek do zwracania predefiniowanych wyników Używanie atrap do weryfikowania interakcji Kiedy użycie zamienników testowych jest uzasadnione? Nie nadużywajmy atrap Nie róbmy atrap zewnętrznego kodu Nie róbmy atrap obiektów reprezentujących wartość Nie da się tworzyć atrap bez wstrzykiwania zależności Nie testujmy atrap Pracujemy z Mockito — popularną biblioteką do tworzenia zamienników testowych Rozpoczynamy pracę z Mockito Używamy Mockito do utworzenia zaślepki Używamy Mockito do utworzenia atrapy Zacieranie się rozróżnienia między zaślepkami a atrapami Dopasowywanie argumentów — niestandardowe zachowanie zamienników testowych Projektowanie kodu obsługującego błędy z użyciem testów Testowanie obsługi błędów w grze Wordz Architektura heksagonalna — oddzielenie systemów zewnętrznych Dlaczego systemy zewnętrzne są przyczyną trudności? Problemy ze środowiskiem Omyłkowe wywołanie prawdziwych procesów podczas wykonywania testów Jakich danych powinniśmy oczekiwać? Wywołania systemowe i czas systemowy Wyzwania związane z usługami stron trzecich Odwrócenie zależności na ratunek Generalizowanie w kierunku architektury heksagonalnej Przegląd elementów architektury heksagonalnej Złota zasada: domena nigdy nie łączy się bezpośrednio z adapterami Skąd kształt sześcioboku? Tworzenie abstrakcji systemu zewnętrznego Czego potrzebuje model domeny? Pisanie kodu domeny Co powinno się znaleźć w modelu domeny? Użycie bibliotek i frameworków w modelu domeny Wybór stylu programowania Tworzenie testowych zamienników systemów zewnętrznych Zastępowanie adapterów zamiennikami testowymi Tworzenie testów jednostkowych większych jednostek Testy jednostkowe całych historyjek użytkownika Tworzenie abstrakcji bazy danych w aplikacji Wordz Projektowanie interfejsów repozytoriów Projektowanie adapterów bazy danych i generatora liczb losowych Testy FIRST i piramida testów Piramida testów Testy jednostkowe zgodne z zasadami FIRST Testy integracyjne Testowanie adapterów bazodanowych Testowanie usług sieciowych Testowanie zgodności kontraktu z wymaganiami konsumenta Testy przekrojowe i testy akceptacji przez użytkownika Narzędzia do testów akceptacyjnych Procesy CI/CD i środowiska testowe Dlaczego potrzebujemy ciągłej integracji? dostarczania? Ciągłe dostarczanie czy ciągłe wdrażanie? Praktyczne aspekty procesów CI/CD Środowiska testowe Testowanie na produkcji Test integracyjny bazy danych dla gry Wordz Pobieranie słowa z bazy danych TDD jako część zapewnienia jakości Metodyka TDD i jej miejsce w szerszym kontekście zapewnienia jakości Rozumienie ograniczeń TDD Czy to oznacza, że testy manualne nie są potrzebne? Manualne testy eksploracyjne i odkrywanie nieoczekiwanego Przeglądy kodu i programowanie zespołowe Testowanie interfejsu i doświadczeń użytkownika Testowanie interfejsu użytkownika Ocena doświadczeń użytkownika Testowanie bezpieczeństwa i monitorowanie utrzymania Włączanie manualnych elementów w procesy CI/CD Dodawanie testów na początku Podejście „testy najpierw” jako narzędzie do projektowania Testy stanowią wykonywalną specyfikację Podejście „testy najpierw” przekłada się na wartościowe wskaźniki pokrycia kodu Wystrzegajmy się określania progów pokrycia kodu Zaczynanie pracy od testów pomaga w ciągłym dostarczaniu „Zawsze możemy napisać testy później, prawda?” Dla początkujących podejście „testy później” jest łatwiejsze niż TDD W podejściu z późniejszym testowaniem trudniej przetestować każdą ścieżkę Podejście z późniejszym testowaniem ma mniejszy wpływ na projektowanie Późniejsze testowanie może nigdy się nie wydarzyć „Testy? Testy są dla ludzi, którzy nie potrafią programować!” Co się dzieje, jeżeli nie testujemy w trakcie rozwoju oprogramowania? Testowanie od wewnątrz na zewnątrz wewnątrz Określanie granic testów dzięki architekturze heksagonalnej Podejście dośrodkowe działa dobrze z modelem domeny Podejście dośrodkowe współgra z adapterami Historyjki użytkownika można testować w modelu domeny TDD w prawdziwym życiu Tworzenie warstwy domeny Rozpoczęcie nowej gry Sterowane testami projektowanie rozpoczęcia nowej gry Śledzenie postępu w grze Triangulacja wyboru słowa Granie w grę Projektowanie interfejsu oceny próby Triangulacja śledzenia postępu gry Reakcja na poprawną próbę Triangulacja zakończenia gry ze względu na liczbę niepoprawnych prób Triangulacja odpowiedzi na próbę po końcu gry Przegląd projektu Tworzenie warstwy bazodanowej Instalowanie bazy danych PostgreSQL Tworzenie testu integracji z bazą danych Tworzenie testu bazy danych z użyciem biblioteki DBRider Tworzenie kodu produkcyjnego Implementacja adaptera WordRepository Dostęp do bazy danych Implementacja GameRepository Tworzenie warstwy sieciowej Rozpoczęcie nowej gry Dodanie wymaganych bibliotek do projektu Pisanie testu kończącego się niepowodzeniem Utworzenie własnego serwera HTTP Dodawanie ścieżek do serwera HTTP Podłączenie do warstwy domeny Refaktoryzacja kodu rozpoczynającego grę Obsługa błędów podczas rozpoczęcia gry Naprawa testów nieoczekiwanie kończących się niepowodzeniem Połączenie komponentów aplikacji w całość Używanie aplikacji