Testy jednostkowe. Świat niezawodnych aplikacji

Description

System informatyczny to inteligentne połączenie modułów i zależności, otoczone setkami tysięcy, a nawet milionami linii kodu źródłowego. Zmiana w jednym obszarze może mieć fatalny wpływ na działanie systemu w zupełnie innym miejscu. Ta zależność prowadzi do ogromnych kosztów wprowadzenia nawet najdrobniejszej zmiany w oprogramowaniu. Czy istnieje rozwiązanie tego problemu? Jak stworzyć system, w którym błyskawiczna weryfikacja lub wprowadzona zmiana nie spowodują nowych błędów w innej części? Oczywiście, że można to zrobić! Odpowiedzią na te i wiele innych problemów są testy automatyczne. Ten przewodnik to doskonała okazja, by głębiej poznać temat testów jednostkowych. Jeżeli uważasz, że ich pisanie jest uciążliwe, czasochłonne, trudne lub po prostu nie wiesz, jak je tworzyć, ta książka rozwiąże wszystkie Twoje problemy! W trakcie lektury dowiesz się, jak pisać testy, tworzyć zestawy testowe oraz przygotowywać makiety i namiastki. Poznasz narzędzia Moq, FakeItEasy oraz Typemock Isolator. Ponadto zdobędziesz wiedzę na temat organizacji testów oraz strategii testowania kodu odziedziczonego. Książka ta jest obowiązkową lekturą dla wszystkich programistów C# szukających świetnego przewodnika po świecie testów jednostkowych! Dzięki tej książce: Spis treści Słowo wstępne do drugiego wydania Słowo wstępne do pierwszego wydania Przedmowa Podziękowania O tej książce O ilustracji na okładce Część I. Zaczynamy Rozdział 1. Podstawowe informacje o testach jednostkowych 1.1. Definicja testu jednostkowego krok po kroku 1.1.1. Dlaczego ważne jest pisanie „dobrych” testów jednostkowych 1.1.2. Wszyscy piszemy testy jednostkowe (w pewnym sensie) 1.2. Właściwości dobrego testu jednostkowego 1.3. Testy integracyjne 1.3.1. Wady niezautomatyzowanych testów integracyjnych w porównaniu z automatycznymi testami jednostkowymi 1.4. Co sprawia, że test jednostkowy jest dobry 1.5. Prosty przykład testu jednostkowego 1.6. Wytwarzanie oprogramowania sterowane testami 1.7. Trzy zasadnicze umiejętności potrzebne do skutecznego stosowania technik TDD 1.8. Podsumowanie Rozdział 2. Pierwszy test jednostkowy 2.1. Frameworki testów jednostkowych 2.1.1. Co oferują frameworki testów jednostkowych 2.1.2. Frameworki xUnit 2.2. Wprowadzenie w tematykę projektu LogAn 2.3. Pierwsze kroki z NUnit 2.3.1. Instalacja frameworka NUnit 2.3.2. Ładowanie rozwiązania 2.3.3. Wykorzystanie atrybutów NUnit w kodzie 2.4. Piszemy pierwszy test 2.4.1. Klasa Assert 2.4.2. Uruchomienie pierwszego testu za pomocą frameworka NUnit 2.4.3. Dodanie testów pozytywnych 2.4.4. Od czerwonego do zielonego: dążenie do spełnienia testów 2.4.5. Styl kodu testów 2.5. Refaktoryzacja w kierunku testów z parametrami 2.6. Więcej atrybutów NUnit 2.6.1. Atrybuty Setup i TearDown 2.6.2. Testowanie występowania oczekiwanych wyjątków 2.6.3. Ignorowanie testów 2.6.4. Składnia fluent frameworka NUnit 2.6.5. Ustawianie kategorii testowych 2.7. Testowanie wyników metod, które nie zwracają wartości, tylko zmieniają stan systemu 2.8. Podsumowanie Część II. Podstawowe techniki Rozdział 3. Wykorzystanie namiastek do rozwiązywania zależności 3.1. Wprowadzenie w tematykę namiastek 3.2. Identyfikacja zależności od systemu plików w klasie LogAnalyzer 3.3. Określenie sposobu łatwego testowania klasy LogAnalyzer 3.4. Refaktoryzacja projektu w celu ułatwienia testowania 3.4.1. Wyodrębnienie interfejsu umożliwiającego zastąpienie istniejącej implementacji 3.4.2. Wstrzykiwanie zależności: wstrzyknięcie sztucznej implementacji do testowanej jednostki 3.4.3. Wstrzyknięcie sztucznego obiektu na poziomie konstruktora 3.4.4. Symulowanie wyjątków z poziomu sztucznych obiektów 3.4.5. Wstrzyknięcie sztucznego obiektu za pomocą gettera lub settera właściwości 3.4.6. Wstrzyknięcie sztucznego obiektu bezpośrednio przed wywołaniem metody 3.5. Odmiany technik refaktoryzacji 3.5.1. Wykorzystanie techniki „wyodrębnij i przesłoń” do tworzenia sztucznych wyników 3.6. Pokonanie problemu hermetyzacji 3.6.1. Korzystanie ze składowych internal oraz atrybutu [InternalsVisibleTo] 3.6.2. Wykorzystanie atrybutu [Conditional] 3.6.3. Korzystanie z dyrektyw #if i #endif do warunkowej kompilacji 3.7. Podsumowanie Rozdział 4. Testowanie interakcji z wykorzystaniem obiektów-makiet 4.1. Testy bazujące na wartości, testy bazujące na stanach a testy integracyjne 4.2. Różnica pomiędzy obiektami-makietami a namiastkami 4.3. Napisany ręcznie prosty przykład obiektu-makiety 4.4. Wykorzystywanie obiektów-makiet razem z namiastkami 4.5. Jedna makieta na test 4.6. Łańcuch sztucznych obiektów: namiastki, które generują makiety lub inne namiastki 4.7. Problemy z pisanymi ręcznie makietami i namiastkami 4.8. Podsumowanie Rozdział 5. Frameworki izolacji 5.1. Dlaczego stosujemy frameworki izolacji? 5.2. Dynamiczne tworzenie sztucznych obiektów 5.2.1. Wykorzystanie frameworka NSubstitute w testach 5.2.2. Zastąpienie sztucznego obiektu napisanego ręcznie obiektem dynamicznym 5.3. Symulacja sztucznych wartości 5.3.1. Wprowadzamy do testu makietę razem z namiastką 5.4. Testowanie działań związanych ze zdarzeniami 5.4.1. Testowanie obiektu nasłuchującego zdarzenia 5.4.2. Testowanie, czy zostało wyzwolone zdarzenie 5.5. Współczesne frameworki izolacji dla środowiska .NET 5.6. Zalety i pułapki frameworków izolacji 5.6.1. Pułapki, których należy unikać w przypadku korzystania z frameworków izolacji 5.6.2. Nieczytelny kod testu 5.6.3. Weryfikacja niewłaściwych rzeczy 5.6.4. Więcej niż jedna makieta w teście 5.6.5. Nadspecyfikacja testów 5.7. Podsumowanie Rozdział 6. Bardziej zaawansowane zagadnienia związane z frameworkami izolacji 6.1. Frameworki ograniczone i nieograniczone 6.1.1. Frameworki ograniczone 6.1.2. Frameworki nieograniczone 6.1.3. Jak działają nieograniczone frameworki bazujące na profilerze 6.2. Wartość dobrych frameworków izolacji 6.3. Własności wspierające długowieczność i użyteczność 6.3.1. Imitacje rekurencyjne 6.3.2. Domyślne ignorowanie argumentów 6.3.3. Rozległe imitacje 6.3.4. Nieścisłe zachowania sztucznych obiektów 6.3.5. Nieścisłe makiety 6.4. Antywzorce projektowe frameworków izolacji 6.4.1. Mylące pojęcia 6.4.2. Zarejestruj i odtwórz 6.4.3. Lepkie zachowania 6.4.4. Złożona składnia 6.5. Podsumowanie Część III. Kod testu Rozdział 7. Hierarchie testów i ich organizacja 7.1. Testy uruchamiane w ramach automatycznych kompilacji 7.1.1. Anatomia skryptu kompilacji 7.1.2. Inicjowanie kompilacji i integracji 7.2. Klasyfikacja testów na podstawie szybkości i typu 7.2.1. Czynnik ludzki oddzielenia testów jednostkowych od testów integracyjnych 7.2.2. Bezpieczna zielona strefa 7.3. Zadbanie o umieszczenie testów w repozytorium z kodem źródłowym 7.4. Odwzorowanie klas testowych na testowany kod 7.4.1. Odwzorowanie testów na projekty 7.4.2. Odwzorowanie testów na klasy 7.4.3. Odwzorowanie testów na punkty wejścia metod konkretnych jednostek pracy 7.5. Wstrzykiwanie zależności cross-cutting 7.6. Budowanie API obsługi testów dla aplikacji 7.6.1. Wykorzystanie wzorców dziedziczenia w klasach testowych 7.6.2. Tworzenie narzędziowych klas i metod obsługi testów 7.6.3. Zapoznanie deweloperów ze stworzonym API 7.7. Podsumowanie Rozdział 8. Filary dobrych testów jednostkowych 8.1. Pisanie wiarygodnych testów 8.1.1. Decydowanie o tym, kiedy należy usunąć lub zmodyfikować testy 8.1.2. Unikanie logiki w testach 8.1.3. Testowanie tylko jednego aspektu 8.1.4. Oddzielenie testów jednostkowych od integracyjnych 8.1.5. Zapewnienie przeglądów kodu 8.2. Pisanie testów łatwych w utrzymaniu 8.2.1. Testowanie metod prywatnych lub chronionych 8.2.2. Usuwanie duplikatów 8.2.3. Korzystanie z metod konfiguracyjnych w sposób ułatwiający utrzymanie 8.2.4. Wymuszanie izolacji testu 8.2.5. Unikanie wielu asercji dotyczących różnych aspektów 8.2.6. Porównywanie obiektów 8.2.7. Unikanie nadmiernej specyfikacji 8.3. Pisanie czytelnych testów 8.3.1. Nazwy testów jednostkowych 8.3.2. Nazwy zmiennych 8.3.3. Dobre komunikaty asercji 8.3.4. Oddzielenie asercji od akcji 8.3.5. Konfigurowanie i rozbiórka 8.4. Podsumowanie Część IV. Projektowanie i proces Rozdział 9. Wdrażanie testów jednostkowych w organizacji 9.1. Jak zostać agentem zmian? 9.1.1. Bądź przygotowany na trudne pytania 9.1.2. Przekonaj inne osoby z organizacji: mistrzów i oponentów 9.1.3. Określenie możliwych punktów wejścia 9.2. Sposoby na odniesienie sukcesu 9.2.1. Wdrożenie po partyzancku (dół-góra) 9.2.2. Przekonanie kierownictwa (góra-dół) 9.2.3. Mistrz z zewnątrz 9.2.4. Zadbanie o widoczność postępów 9.2.5. Dążenie do konkretnych celów 9.2.6. Uświadomienie sobie istnienia przeszkód 9.3. Czynniki wpływające na porażkę 9.3.1. Brak siły napędowej 9.3.2. Brak politycznego wsparcia 9.3.3. Złe implementacje i pierwsze wrażenia 9.3.4. Brak wsparcia ze strony zespołu 9.4. Czynniki wpływające na zachowania członków zespołu 9.5. Trudne pytania i odpowiedzi 9.5.1. Ile dodatkowego czasu będzie trzeba poświęcić? 9.5.2. Czy ze względu na wprowadzenie testów jednostkowych będzie zagrożone moje stanowisko inżyniera jakości? 9.5.3. Skąd wiemy, że testy jednostkowe się sprawdzają? 9.5.4. Czy istnieje dowód, że testy jednostkowe pomagają? 9.5.5. Dlaczego dział kontroli jakości ciągle znajduje błędy? 9.5.6. Istnieje mnóstwo kodu, dla którego nie ma testów. Od czego zacząć? 9.5.7. Kodujemy w kilku językach czy testy jednostkowe są wykonalne? 9.5.8. Co zrobić, jeśli produkt obejmuje kombinację oprogramowania i sprzętu? 9.5.9. Skąd możemy wiedzieć, że nie ma błędów w testach? 9.5.10. Debuger pokazuje, że mój kod działa do czego są mi potrzebne testy? 9.5.11. Czy trzeba stosować kodowanie w stylu TDD? 9.6. Podsumowanie Rozdział 10. Praca z kodem odziedziczonym 10.1. Od czego należy zacząć przy dodawaniu testów? 10.2. Wybór strategii selekcji 10.2.1. Plusy i minusy strategii „najpierw łatwe” 10.2.2. Plusy i minusy strategii „najpierw trudne” 10.3. Pisanie testów integracyjnych przed refaktoryzacją 10.4. Ważne narzędzia do testów jednostkowych odziedziczonego kodu 10.4.1. Łatwe izolowanie zależności za pomocą frameworków izolacji bez ograniczeń 10.4.2. Wykorzystanie programu JMockit do pracy z kodem odziedziczonym w Javie 10.4.3. Wykorzystanie programu Vise do refaktoryzacji kodu w Javie 10.4.4. Przeprowadzenie testów akceptacyjnych przed refaktoryzacją 10.4.5. Przeczytaj książkę Michaela Feathersa na temat pracy z kodem odziedziczonym 10.4.6. Wykorzystanie programu NDepend do analizy kodu produkcyjnego 10.4.7. Wykorzystanie programu ReSharper do refaktoryzacji i poruszania się po kodzie produkcyjnym 10.4.8. Wykrywanie powielonego kodu (oraz błędów) za pomocą narzędzi Simian i TeamCity 10.5. Podsumowanie Rozdział 11. Projekt a sprawdzalność 11.1. Dlaczego należy dbać o sprawdzalność podczas projektowania? 11.2. Sprawdzalność jako cel projektowy 11.2.1. Domyślne stosowanie metod wirtualnych 11.2.2. Projekt bazujący na interfejsach 11.2.3. Domyślne stosowanie klas niezapieczętowanych 11.2.4. Unikanie tworzenia egzemplarzy klas skonkretyzowanych wewnątrz metod zawierających logikę 11.2.5. Unikanie bezpośrednich wywołań do metod statycznych 11.2.6. Unikanie konstruktorów lub konstruktorów statycznych zawierających logikę 11.2.7. Oddzielenie logiki singletona od posiadaczy singletona 11.3. Plusy i minusy projektowania z myślą o sprawdzalności 11.3.1. Ilość pracy 11.3.2. Złożoność 11.3.3. Eksponowanie wrażliwych IP 11.3.4. Czasami nie można 11.4. Alternatywy dla projektowania z myślą o sprawdzalności 11.4.1. Dyskusje o projektach i języki o dynamicznych typach 11.5. Przykład projektu trudnego do testowania 11.6. Podsumowanie 11.7. Dodatkowe materiały Dodatek A. Narzędzia i frameworki A.1. Frameworki izolacji A.1.1. Moq A.1.2. Rhino Mocks A.1.3. Typemock Isolator A.1.4. JustMock A.1.5. Microsoft Fakes (Moles) A.1.6. NSubstitute A.1.7 FakeItEasy A.1.8. Foq A.1.9. Isolator++ A.2. Frameworki testów A.2.1. Mighty Moose (znany także pod nazwą Continuous Tests) — silnik testów działający ciągle A.2.2. NCrunch — silnik testów działający ciągle A.2.3. Silnik testów Typemock Isolator A.2.4. Silnik testów CodeRush A.2.5. Silnik testów ReSharper A.2.6. TestDriven.NET A.2.7. Silnik testów NUnit z interfejsem GUI A.2.8. MSTest A.2.9. Pex A.3. API testów A.3.1 MSTest API — framework testów jednostkowych firmy Microsoft A.3.2. MSTest for Metro Apps (Windows Store) A.3.3. NUnit API A.3.4. xUnit.NET A.3.5. Pomocniczy API Fluent Assertions A.3.6. Pomocniczy API Shouldly A.3.7. Pomocniczy API SharpTestsEx A.3.8. Pomocniczy API AutoFixture A.4. Kontenery IoC A.4.1. Autofac A.4.2. Ninject A.4.3. Castle Windsor A.4.4. Microsoft Unity A.4.5. StructureMap A.4.6. Microsoft Managed Extensibility Framework A.5. Testowanie baz danych A.5.1. Wykorzystywanie testów integracyjnych dla warstwy danych A.5.2. Wykorzystanie klasy TransactionScope w celu cofania zmian w danych A.6. Testowanie stron WWW A.6.1. Ivonna A.6.2. Team System Web Test A.6.3. Watir A.6.4. Selenium Web Driver A.6.5 Coypu A.6.6. Capybara A.6.7. Testowanie JavaScript A.7. Testowanie interfejsu użytkownika (w aplikacjach desktop) A.8. Testowanie aplikacji wielowątkowych A.8.1. Microsoft CHESS A.8.2. Osherove.ThreadTester A.9. Testy akceptacyjne A.9.1. FitNesse A.9.2. SpecFlow A.9.3. Cucumber A.10. Frameworki API w stylu BDD Skorowidz