Jesteśmy społecznością, która kocha książki

Kolejny wpis programistyczny. Książka ta kiedyś była polecana przez Maciej Aniserowicza (z 5 lat temu, przed jego zmianą paradygmatu działania). Pierwsza cześć lektury była bardzo dobra - ugruntowałem sobie wiedzę wyniesiona z lat praktyki. Niestety końcowe przemyślenia autora były dość chaotyczne. Mimo wszystko polecam. Kilka wskazówek, które mogą się przydać, jeśli ktoś chce zwiększyć swoje umiejętności pisania testów: -Assert.Throws() jest lepsze niż atrybut (adnotacja) Expected, bo dokładnie wskazujemy, gdzie, i w jakiej metodzie, powinien zostać wyrzucony wyjątek -Fabryka do inicjalizacji obiektu, na którym wykonujemy testy, to najlepsze rozwiązanie przy tworzeniu testów -Szwy to miejsca, w których można podłączyć różne funkcjonalności - namiastki (stuby) -Nie wiedziałem ze w środowisku .Net jest tryb warunkowej kompilacji. -Różnica między namiastką a obiektem - makietą (mockiem) jest taka, że mock zapisuje stan i zazwyczaj asercje są wykonywane na tym mocku i sprawdzają ten stan. -Zaleca się tworzenie tylko jednego mocka na test i resztę namiastek. Więcej niż jeden mock oznacza, że testujemy więcej funkcjonalności niż jedną i powinniśmy rozbić metodę. -Testy nie powinny sprawdzać czy zostały wywołane namiastki bo zakończy się to stanem "testing hell" -Zamiast porównywać całe obiekty lepiej porównywać kilka właściwości za pomocą mechanizmow dopasowywania właściwości (String.contains etc). Inaczej wpadamy w tzw. “testing hell” -Zbyt wiele makiet zmniejsza czytelność kodu. Poza tym pojedynczy test powinien sprawdzać jedną funkcjonalność “zamockowana” (najlepiej przez 1 mock) -Gdy to możliwe należy unikać tworzenia obiektów makiet na rzecz namiastek (stosunek 1/20 to granica funkcjonalnych testów) -Frameworki izolacji nazywane ograniczonymi to takie, które nie potrafią imitować metod statycznych, nie wirtualnych i prywatnych. Frameworki te po prostu generują kod danych makiet namiastek w trakcie trwania testu -Bardzo dobry sposób testowania zależności od czasu to stosowanie w calym projekcie klasy, w której można arbitralnie wprowadzić czas -Dodając testy jednostkowe do dużych projektów warto zacząć od testów integracyjnych, które sprawią, że na pewno dodanie testów jednostkowych i refaktoryzacja niczego nie popsuje