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

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ś...