Twórz niezawodne aplikacje w języku Python!

• Poznaj sposób pracy wykorzystujący podejście TDD, między innymi cykl test jednostkowy i tworzenie kodu, a później refaktoryzacja.
• Używaj testów jednostkowych dla klas i funkcji oraz testów funkcjonalnych pozwalających na symulowanie działań podejmowanych przez użytkownika w przeglądarce internetowej.
• Dowiedz się kiedy i jak używać obiektów imitacji, a także poznaj wady i zalety testów odizolowanych i zintegrowanych.
• Przetestuj i automatyzuj wdrożenie za pomocą serwera prowizorycznego.
• Zastosuj testy względem przygotowanych przez firmy trzecie wtyczek, które integrujesz z witryną.
• Używaj środowiska ciągłej integracji w celu automatycznego wykonywania testów.

Rozdziały:

Wprowadzenie (13)

Przygotowania i założenia (19)

Podziękowania (25)

I. PODSTAWY TDD I DJANGO (27)

1. Konfiguracja Django za pomocą testu funkcjonalnego (29)

• Słuchaj Testing Goat! Nie rób nic, dopóki nie przygotujesz testu (29)
• Rozpoczęcie pracy z frameworkiem Django (32)
• Utworzenie repozytorium Git (33)

2. Rozszerzenie testu funkcjonalnego za pomocą modułu unittest (37)

• Użycie testu funkcjonalnego do przygotowania minimalnej aplikacji (37)
• Moduł unittest ze standardowej biblioteki Pythona (40)
• Ukryte oczekiwanie (42)
• Przekazanie plików do repozytorium (42)

3. Testowanie prostej strony głównej za pomocą testów jednostkowych (45)

• Nasza pierwsza aplikacja Django i test jednostkowy (46)
• Testy jednostkowe i różnice dzielące je od testów funkcjonalnych (46)
• Testy jednostkowe w Django (47)
• MVC w Django, adresy URL i funkcje widoku (48)
• Wreszcie zaczynamy tworzyć kod aplikacji (49)
• urls.py (51)
• Testy jednostkowe widoku (53)
  • Cykl test jednostkowy - tworzenie kodu (54)

4. Do czego służą te wszystkie testy? (57)

• Programowanie przypomina wyciąganie wiadrem wody ze studni (58)
• Użycie Selenium do testowania interakcji użytkownika (59)
• Reguła "nie testuj stałych" i szablony na ratunek (62)
  • Refaktoryzacja w celu użycia szablonu (62)
• Refaktoryzacja (65)
• Nieco więcej o stronie głównej (67)
• Przypomnienie - proces TDD (68)

5. Zapis danych wejściowych użytkownika (73)

• Od formularza sieciowego do wykonania żądania POST (73)
• Przetwarzanie żądania POST w serwerze (76)
• Przekazanie zmiennych Pythona do wygenerowania w szablonie (77)
• Do trzech razy sztuka, a później refaktoryzacja (81)
• Django ORM i nasz pierwszy model (82)
  • Pierwsza migracja bazy danych (84)
  • Zdumiewająco duży postęp w teście (85)
  • Nowa kolumna oznacza nową migrację (85)
• Zapis w bazie danych informacji z żądania POST (86)
• Przekierowanie po wykonaniu żądania POST (89)
  • Poszczególne testy powinny testować pojedyncze rzeczy (89)
• Wygenerowanie elementów w szablonie (90)
• Utworzenie produkcyjnej bazy danych za pomocą polecenia migrate (92)

6. Przygotowanie minimalnej działającej wersji witryny (97)

• Gwarancja izolacji testu w testach funkcjonalnych (97)
  • Wykonanie tylko testów jednostkowych (100)
• Stawiaj na małe projekty (101)
  • YAGNI! (102)
  • REST (102)
• Implementacja nowego projektu za pomocą TDD (103)
• Iteracja w kierunku nowego projektu (105)
• Testowanie widoków, szablonów i adresów URL za pomocą testu klienta Django (107)
  • Nowa klasa testowa (107)
  • Nowy adres URL (108)
  • Nowa funkcja widoku (108)
  • Oddzielny szablon do wyświetlania list (109)
• Kolejny adres URL i widok pozwalający na dodanie elementów listy (112)
  • Klasa testowa dla operacji tworzenia nowej listy (112)
  • Adres URL i widok przeznaczony do tworzenia nowej listy (113)
  • Usunięcie zbędnego kodu i dalsze testy (114)
  • Wskazanie formularzy w nowym adresie URL (115)
• Dostosowanie modeli (116)
  • Związek klucza zewnętrznego (117)
  • Dostosowanie reszty świata do naszych nowych modeli (118)
• Każda lista powinna mieć własny adres URL (120)
  • Przechwytywanie parametrów z adresów URL (121)
  • Dostosowanie new_list do nowego świata (122)
• Jeszcze jeden widok pozwalający na dodanie elementu do istniejącej listy (123)
  • Uwaga na żarłoczne wyrażenia regularne! (124)
  • Ostatni nowy adres URL (124)
  • Ostatni nowy widok (125)
  • Jak można użyć adresu URL w formularzu? (126)
• Ostatnia refaktoryzacja za pomocą polecenia include (128)

II. PROGRAMOWANIE SIECIOWE (131)

7. Upiększanie - jak przetestować układ i style? (133)

• Jaką funkcjonalność należy testować w przypadku układu i stylów? (133)
• Upiększanie za pomocą frameworka CSS (136)
• Dziedziczenie szablonu w Django (137)
• Integracja z frameworkiem Bootstrap (139)
  • Wiersze i kolumny (139)
• Pliki statyczne w Django (140)
  • Zaczynamy używać klasy StaticLiveServerCase (141)
• Użycie komponentów Bootstrap do poprawy wyglądu witryny (142)
  • Jumbotron (142)
  • Ogromne pola danych wejściowych (143)
  • Nadanie stylu tabeli (143)
• Użycie własnych arkuszy stylów CSS (143)
• Co zostało zatuszowane - polecenie collectstatic i inne katalogi statyczne (144)
• Kilka tematów, które nie zostały omówione (147)

8. TDD na przykładzie witryny prowizorycznej (149)

• Techniki TDD i niebezpieczeństwa związane z wdrożeniem (150)
• Jak zwykle zaczynamy od testu (151)
• Pobranie nazwy domeny (153)
• Ręczne przygotowanie serwera do hostingu naszej witryny (153)
  • Wybór hostingu dla witryny (154)
  • Uruchomienie serwera (154)
  • Konto użytkownika, SSH i uprawnienia (155)
  • Instalacja Nginx (155)
  • Konfiguracja domen dla witryn prowizorycznej i rzeczywistej (156)
  • Użycie testów funkcjonalnych do potwierdzenia działania domeny i serwera Nginx (157)
• Ręczne wdrożenie kodu (157)
  • Dostosowanie położenia bazy danych (158)
  • Utworzenie virtualenv (159)
  • Prosta konfiguracja Nginx (162)
  • Utworzenie bazy danych za pomocą polecenia migrate (164)
• Wdrożenie w środowisku produkcyjnym (164)
  • Użycie Gunicorn (164)
  • Użycie Nginx do obsługi plików statycznych (165)
  • Użycie gniazd systemu Unix (166)
  • Przypisanie opcji DEBUG wartości False i ustawienie ALLOWED_HOSTS (167)
  • Użycie Upstart do uruchamiania Gunicorn wraz z systemem (168)
  • Zachowanie wprowadzonych zmian - dodanie Gunicorn do pliku requirements.txt (168)
• Automatyzacja (169)
  • Zachowanie informacji o postępie (172)

9. Zautomatyzowane wdrożenie za pomocą Fabric (173)

• Analiza skryptu Fabric dla naszego wdrożenia (174)
• Wypróbowanie rozwiązania (177)
  • Wdrożenie w środowisku produkcyjnym (179)
  • Pliki konfiguracyjne Nginx i Gunicorn odtworzone za pomocą sed (180)
• Użycie polecenia git tag do oznaczenia wydania (181)
• Dalsza lektura (181)

10. Weryfikacja danych wejściowych i organizacja testu (183)

• Testy funkcjonalne weryfikacji danych - ochrona przed pustymi elementami (183)
  • Pominięcie testu (184)
  • Podział testów funkcjonalnych na wiele plików (185)
  • Wykonanie pojedynczego pliku testu (187)
  • Podparcie testów funkcjonalnych (188)
• Sprawdzenie warstwy modelu (189)
  • Refaktoryzacja testów jednostkowych na oddzielne pliki (189)
  • Testy jednostkowe sprawdzania modelu oraz menedżer kontekstu self.assertRaises() (190)
  • Dziwactwo Django - zapis modelu nie wywołuje operacji sprawdzenia poprawności (191)
• Wyświetlanie w widoku błędów z weryfikacji modelu (192)
  • Upewnienie się, że nieprawidłowe dane nie zostaną zapisane w bazie danych (194)
• Wzorzec Django - przetwarzanie żądań POST w widoku generującym formularz (196)
  • Refaktoryzacja - przekształcenie funkcjonalności new_item na view_list (197)
  • Egzekwowanie w widoku view_list weryfikacji modelu (199)
• Refaktoryzacja - usunięcie na stałe zdefiniowanych adresów URL (200)
  • Znacznik szablonu {% url %} (200)
  • Użycie get_absolute_url w przekierowaniach (201)

11. Prosty formularz (205)

• Przeniesienie do formularza logiki odpowiedzialnej za sprawdzanie poprawności danych (205)
  • Użycie testu jednostkowego do analizy API formularzy (206)
  • Przejście do Django ModelForm (208)
  • Testowanie i dostosowanie do własnych potrzeb logiki weryfikacji formularza (209)
• Użycie formularza w widokach (210)
  • Użycie formularza w widoku za pomocą żądania GET (211)
  • Duża operacja znajdź i zastąp (213)
• Użycie formularza w widoku obsługującym żądania POST (215)
  • Adaptacja testów jednostkowych dla widoku new_list (215)
  • Użycie formularza w widoku (216)
  • Użycie formularza w celu wyświetlenia błędów w szablonie (216)
• Użycie formularza w innym widoku (217)
  • Metoda pomocnicza dla wielu krótkich testów (218)
• Użycie metody save() formularza (220)

12. Bardziej skomplikowane formularze (223)

• Kolejny test funkcjonalny dotyczący powielonych elementów (223)
  • Ochrona przed duplikatami w warstwie modelu (224)
  • Mała dygresja dotycząca kolejności API Querystring i przedstawiania ciągu tekstowego (226)
  • Przepisanie testu starego modelu (228)
  • Pewne błędy spójności ujawniają się podczas zapisu (229)
• Eksperymenty w warstwie widoku sprawdzające, czy są powielone elementy (230)
• Bardziej skomplikowany formularz do obsługi unikalności elementów (231)
• Użycie istniejącego formularza w widoku listy (232)

13. Zagłębiamy się ostrożnie w JavaScript (237)

• Rozpoczynamy od testów funkcjonalnych (237)
• Konfiguracja prostego silnika wykonywania testów JavaScript (238)
• Użycie jQuery i stałych elementów
  (240)
• Utworzenie testu jednostkowego JavaScript dla żądanej funkcjonalności (243)
• Testowanie JavaScript w cyklu TDD (245)
• Zdarzenie onload i przestrzenie nazw (245)
• Kilka rozwiązań, które się nie sprawdzają (246)

14. Wdrożenie nowego kodu (247)

• Wdrożenie prowizoryczne (247)
• Wdrożenie rzeczywiste (247)
• A jeśli wystąpi błąd bazy danych? (248)
• Podsumowanie - git tag i nowe wydanie (248)

III. BARDZIEJ ZAAWANSOWANE ZAGADNIENIA (249)

15. Użycie JavaScript do uwierzytelniania użytkownika, integracji wtyczek i przygotowania imitacji (251)

• Mozilla Persona (BrowserID) (252)
• Kod eksperymentalny, czyli "Spiking" (252)
  • Utworzenie nowej gałęzi dla Spike (253)
  • Łączenie kodu JavaScript i interfejsu użytkownika (253)
  • Protokół Browser-ID (254)
  • Kod po stronie serwera - niestandardowe uwierzytelnienie (255)
• Zamiana rozwiązania eksperymentalnego na zwykłe (260)
  • Często stosowana technika Selenium - wyraźne oczekiwanie (262)
  • Wycofanie kodu eksperymentalnego (264)
• Testy jednostkowe JavaScript obejmujące komponenty zewnętrzne - nasze pierwsze imitacje (265)
  • Porządkowanie - katalog plików statycznych dla całej witryny (265)
  • Imitacja: kto, co i dlaczego? (266)
  • Przestrzenie nazw (267)
  • Prosta imitacja dla testów jednostkowych dla naszej funkcji inicjującej (267)
  • Bardziej zaawansowane imitacje (272)
  • Sprawdzenie wywołania argumentów (275)
  • Konfiguracja QUnit i testowanie żądań Ajax (276)
  • Więcej zagnieżdżonych wywołań zwrotnych! Testowanie kodu asynchronicznego (280)

16. Uwierzytelnianie po stronie serwera i imitacje w Pythonie (283)

• Rzut oka na wersję eksperymentalną widoku logowania (283)
• Imitacje w Pythonie (284)
  • Testowanie widoku za pomocą imitacji funkcji uwierzytelnienia (284)
  • Sprawdzenie, czy widok faktycznie loguje użytkownika (286)
• Zmiana eksperymentalnej wersji uwierzytelniania na zwykłą - imitacja żądania internetowego (290)
  • Polecenie if oznacza więcej testów (291)
  • Poprawki na poziomie klasy (292)
  • Strzeż się imitacji w porównaniach wartości boolowskich (295)
  • Utworzenie użytkownika, jeśli to konieczne (296)
  • Metoda get_user() (296)
• Minimalny niestandardowy model użytkownika (298)
  • Małe rozczarowanie (300)
  • Testy jako dokumentacja (301)
  • Użytkownicy są uwierzytelnieni (301)
• Chwila prawdy - czy testy funkcjonalne zostaną zaliczone? (302)
• Zakończenie testu funkcjonalnego, przetestowanie wylogowania (303)

17. Konfiguracja testu, rejestracja i debugowanie po stronie serwera (307)

• Pominięcie procesu logowania przez wstępne utworzenie sesji (307)
  • Sprawdzamy rozwiązanie (309)
• Dowód znajdziesz w praktyce - użycie wersji prowizorycznej do wychwycenia błędów (310)
  • Konfiguracja rejestracji danych (311)
  • Usunięcie błędu systemu Persona (312)
• Zarządzanie testową bazą danych w serwerze prowizorycznym (314)
  • Polecenie Django służące do tworzenia sesji (314)
  • Test funkcjonalny uruchamiający w serwerze narzędzie zarządzania (315)
  • Dodatkowy krok za pomocą modułu subprocess (317)
• Zachowanie kodu odpowiedzialnego za rejestrację danych (320)
  • Użycie konfiguracji hierarchicznej rejestracji danych (320)
• Podsumowanie (322)

18. Kończymy "Moje listy" - podejście Outside-In (325)

• Alternatywa, czyli podejście Inside-Out (325)
• Dlaczego preferowane jest podejście Outside-In? (326)
• Test funkcjonalny dla strony Moje listy (326)
• Warstwa zewnętrzna - prezentacja i szablony (327)
• Przejście o jedną warstwę w dół do funkcji widoku (kontroler) (328)
• Kolejne zaliczenie - podejście Outside-In (329)
  • Szybka restrukturyzacja hierarchii dziedziczenia szablonu (329)
  • Projektowanie API za pomocą szablonu (330)
  • Przejście w dół do kolejnej warstwy - co widok przekazuje szablonowi? (331)
• Kolejne "wymaganie" z warstwy widoku - nowe listy powinny "zapamiętywać" swego właściciela (332)
  • Czy przejść do kolejnej warstwy, gdy test kończy się niepowodzeniem? (333)
• Przejście w dół do warstwy modelu (333)
  • Ostatni krok - uzyskanie z poziomu szablonu dostępu do właściciela za pomocą API .name (335)

19. Izolacja i "słuchanie" testów (337)

• Powrót do miejsca, w którym podjęliśmy decyzję - warstwa widoku zależy od nieutworzonego jeszcze kodu modelu (337)
• Pierwsza próba użycia imitacji w celu zapewnienia izolacji (338)
  • Użycie side_effect do sprawdzenia sekwencji zdarzeń (339)
• Posłuchaj testu - brzydki test oznacza konieczność refaktoryzacji (341)
• Ponowne utworzenie testów dla widoku, tym razem w pełni odizolowanych (342)
  • Pozostawienie starych zintegrowanych testów jako punktu odniesienia (342)
  • Nowy zestaw w pełni odizolowanych testów (342)
  • Myślimy w kategoriach współpracy (343)
• Przejście w dół do warstwy formularzy (347)
  • Nadal słuchaj testów - usunięcie kodu ORM z aplikacji (348)
• Wreszcie przechodzimy w dół do warstwy modelu (350)
  • Powrót do widoków (352)
• Moment prawdy (i ryzyko związane z imitacjami) (353)
• Potraktowanie interakcji między warstwami jak kontraktów (354)
  • Identyfikacja niejawnych kontraktów (355)
  • Usunięcie przeoczonego problemu (356)
• Jeszcze jeden test (357)
• Porządkowanie, czyli co zachować z pakietu testów zintegrowanych? (358)
  • Usunięcie powielonego kodu w warstwie formularzy (358)
  • Usunięcie starej implementacji widoku (359)
  • Usunięcie zbędnego kodu w warstwie formularzy (359)
• Podsumowanie - testy odizolowane kontra zintegrowane (360)
  • Niech poziom skomplikowania będzie Twoim przewodnikiem (361)
  • Czy powinienem tworzyć oba rodzaje testów? (361)
  • Do przodu! (362)

20. Ciągła integracja (363)

• Instalacja serwera Jenkins (363)
  • Konfiguracja zabezpieczeń w Jenkins (365)
  • Dodanie wymaganych wtyczek (365)
• Konfiguracja projektu (367)
• Pierwsza kompilacja (368)
• Konfiguracja ekranu wirtualnego, aby testy funkcjonalne można było wykonywać bez monitora (370)
• Wykonanie zrzutów ekranu (371)
• Najczęstszy problem w Selenium - stan wyścigu (374)
• Wykonanie testów QUnit w Jenkins za pomocą PhantomJS (376)
  • Instalacja node (377)
  • Dodanie kolejnych kroków kompilacji w Jenkins (378)
• Więcej zadań do wykonania za pomocą serwera ciągłej integracji (380)

21. Token serwisów społecznościowych, wzorzec strony i ćwiczenie dla czytelnika (381)

• Test funkcjonalny z wieloma użytkownikami i funkcja addCleanup() (381)
• Implementacja w Selenium wzorca interakcja-oczekiwanie (383)
• Wzorzec strony (384)
• Rozszerzenie testu funkcjonalnego na drugiego użytkownika i stronę "Moje listy" (386)
• Ćwiczenie dla czytelnika (388)

22. Szybkie testy, wolne testy i gorąca lawa (391)

• Teza - testy jednostkowe są niezwykle szybkie, mają także inne zalety (392)
  • Szybsze testy oznaczają szybsze tworzenie kodu (392)
  • Uczucie błogostanu (393)
  • Wolne testy nie są wykonywane zbyt często, co przekłada się na gorszej jakości kod (393)
  • Teraz jest dobrze, ale wraz z upływem czasu testy zintegrowane są wykonywane coraz wolniej (393)
  • Nie zabieraj mi tego (393)
  • Testy jednostkowe pozwalają przygotować dobry projekt (394)
• Problemy związane z czystymi testami jednostkowymi (394)
  • Testy odizolowane mogą być trudniejsze w odczycie i zapisie (394)
  • Testy odizolowane nie testują automatycznie integracji (394)
  • Testy jednostkowe rzadko przechwytują nieoczekiwane błędy (394)
  • Testy oparte na imitacji stają się ściśle powiązane z implementacją (394)
  • Jednak wszystkie wymienione problemy można pokonać (395)
• Synteza - jakie mamy oczekiwania wobec testów? (395)
  • Poprawność (395)
  • Czytelny, łatwy w obsłudze kod (395)
  • Produktywna praca (395)
  • Oceń testy pod kątem korzyści, jakich oczekujesz dzięki ich użyciu (396)
• Rozwiązania architektoniczne (396)
  • Porty i adaptery, czysta architektura i architektura heksagonalna (397)
  • Architektura Functional Core, Imperative Shell (398)
• Podsumowanie (398)

Kieruj się Testing Goat! (401)

DODATKI (403)

A. PythonAnywhere (405)

B. Widoki oparte na klasach Django (409)

C. Przygotowanie serwera za pomocą Ansible (419)

D. Testowanie migracji bazy danych (423)

E. Co dalej? (429)

F. Ściąga (433)

G. Bibliografia (437)

Skorowidz (439)