Podejście TDD w Javie. Testowanie, SOLID i architektura heksagonalna jako fundamenty wysokiej jakości Toruń

Koncepcja programowania sterowanego testami oznacza tworzenie kodu wysokiej jakości. TDD (ang. test-driven development) uznaje testowanie za integralny element procesu tworzenia aplikacji. To proste i potężne narzędzie ułatwia także skuteczne zastosowanie wzorców projektowych. Jeśli planujesz zostać biegłym architektem oprogramowania, opanowanie TDD w praktyce jest koniecznością! Dzięki tej książce zrozumiesz moc programowania sterowanego testami. Bazując na świetnie wyjaśnionym procesie budowy przykładowej aplikacji zgodnie z paradygmatem TDD, przyswoisz mechanizmy: cykl czerwone, zielone i refaktoryzacja, a także wzorzec przygotowania, działania i asercji. Dowiesz się też, jak za sprawą odwrócenia zależności i zamienników testowych uzyskać kontrolę nad systemami zewnętrznymi, takimi jak bazy danych. Poznasz ponadto zaawansowane techniki projektowania, w tym zasady SOLID, refaktoryzację i architekturę heksagonalną. Na podstawie piramidy testów nauczysz się znajdować równowagę między szybkimi i powtarzalnymi testami jednostkowymi a testami integracyjnymi. Używając Javy 17, opracujesz nowoczesną mikrousługę REST opartą na bazie danych PostgreSQL. W książce między innymi: kodowanie przypadków testowych w Javie miejsce TDD w procesie tworzenia oprogramowania pisanie w Javie solidnego kodu wielokrotnego użytku rzeczywiste działanie TDD i jego skuteczność przebieg pracy w TDD refaktoryzacja a TDD TDD: Twoja ścieżka do doskonałości w programowaniu! Spis treści: O autorze O recenzentach Wprowadzenie Część 1. Jak doszliśmy do TDD? Rozdział 1. Dlaczego potrzebujemy TDD? Pisanie złego kodu Dlaczego piszemy zły kod? 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 2. TDD w służbie dobrego kodu Projektowanie wysokiej jakości kodu Mów to, co masz na myśli, i miej na myśli to, co mówisz Zajmuj się szczegółami w prywatnych blokach kodu Unikaj zbędnej złożoności 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 3. 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 "Skąd wiemy, że testy są poprawne?" 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? Podsumowanie Pytania i odpowiedzi Polecane źródła Część 2. Techniki TDD Rozdział 4. Tworzymy aplikację z użyciem TDD Wymagania techniczne 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 5. Piszemy pierwszy test Wymagania techniczne 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 Chaotyczne wywołanie Chaotyczne asercje Ograniczenia testów jednostkowych Pokrycie kodu - często bezużyteczny wskaźnik Pisanie złych testów Rozpoczęcie pracy nad aplikacją Wordz Podsumowanie Pytania i odpowiedzi Rozdział 6. Rytm pracy w TDD Wymagania techniczne Stosowanie cyklu czerwone, zielone i refaktoryzacja Czerwone na początek Prostota nade wszystko - przejście do etapu zielonego Refaktoryzacja do czystego kodu Piszemy kolejne testy do gry Wordz Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 7. TDD i SOLID wspierają projektowanie Wymagania techniczne 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 rysującym kształty Podsumowanie Pytania i odpowiedzi Rozdział 8. Zamienniki testowe - zaślepki i atrapy Wymagania techniczne 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 Kiedy używać zaślepek? 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 Kiedy używać 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 9. Architektura heksagonalna - oddzielenie systemów zewnętrznych Wymagania techniczne 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 10. Testy FIRST i piramida testów Wymagania techniczne Piramida testów Testy jednostkowe zgodne z zasadami FIRST Testy integracyjne Co powinny obejmować 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 Co to jest proces CI/CD? Dlaczego potrzebujemy ciągłej integracji? Dlaczego potrzebujemy ciągłego 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 11. 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 12. Testy na początku, później czy nigdy? 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 Nie pisz wszystkich testów na początku 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 Testowanie od zewnątrz do 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Część 3. TDD w prawdziwym życiu Rozdział 13. Tworzenie warstwy domeny Wymagania techniczne 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 Koniec 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 14. Tworzenie warstwy bazodanowej Wymagania techniczne 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 Podsumowanie Pytania i odpowiedzi Polecane źródła Rozdział 15. Tworzenie warstwy sieciowej Wymagania techniczne 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 Granie w grę Połączenie komponentów aplikacji w całość Używanie aplikacji Podsumowanie Pytania i odpowiedzi Polecane źródła O autorze: Alan Mellor pisze kod w C na potrzeby sterowania przemysłowego, w Javie i Go tworzy aplikacje internetowe dla handlu elektronicznego, branży gier i bankowości, a w C++ ... oprogramowanie do magazynowania dokumentów. Współtworzył grę Bounce i symulator lotu dla Red Arrows, Zespołu Akrobacyjnego Królewskich Sił Powietrznych Wielkiej Brytanii.