Definicja testów jednostkowych nie jest jednoznaczna i moim zdaniem zmieniała się przez lata. Jednostkę (“unit”) można w różny sposób interpretować.

Wiele programistów uważa, że należy testować wyłącznie poszczególne klasy. Dobrą stroną takiego podejścia jest fakt, że jak test zakończy się niepowodzeniem, wtedy od razu wiadomo gdzie szukać przyczyny. Przy dobrym zestawie testów, debugger przestaje być potrzebny. 

Osobiście preferuje zupełnie inne podejście. W aplikacjach biznesowych, moim zdaniem aż tak wysoki poziom atomowości nie ma sensu. Jakakolwiek zmiana wymaga wtedy refaktoryzacji istniejących testów, co zniechęca programistów do jakichkolwiek ulepszeń. Utrzymanie kodu po pewnym czasie staje się bardzo trudne i przede wszystkim czasochłonne. 

Aplikacje biznesowe w większości przypadkach nie zawierają skomplikowanej logiki dlatego lepiej testować klasy, które faktycznie są publiczne. Niestety, większość projektów nad jakimi pracowałem, nie przestrzegało poprawnie zasady enkapsulacji klas. Wiele klas tak naprawdę mogłoby być sealed internal. Nie mniej jednak, znając dany projekt, możemy określić punkty wejściowe czy też API do naszej logiki biznesowej. Z tego względu, zamiast testować szczegółowe obiekty biznesowe, lepiej wejść parę poziomów wyżek i skupić się na API, publicznych klasach czy też punktach wejściowych . Z takim podejściem, możemy bezpiecznie refaktoryzować kod i testy powinny pozostać niezmienione!

Dzięki temu,  w większości przypadkach programiści nie muszą martwić się, że zmieniając jakiś kod, zepsują testy. Jeśli testy byłby zbyt szczegółowe, wtedy musielibyśmy modyfikować za każdą refaktoryzacją również testy jednostkowe, co powoduje ogromne niebezpieczeństwo, że coś zostanie po prostu popsute.

Jednostkę definiuję bardziej jako scenariusz biznesowy, a nie szczegół implementacyjny. Oczywiście testy jednostkowe muszą być wykonywane w izolacji i nie mają nic wspólnego z testami integracyjnymi. Po prostu zamiast 5 klas testować osobno, piszę jeden TestFixture, gdzie testy weryfikują wyłącznie pojedyncze scenariusze. W aplikacjach biznesowych sprawdza się to, ponieważ w pojedynczych klasach nie ma aż tak skomplikowanej logiki. Jeśli mam jakieś algorytmy czy bardziej skomplikowaną logikę, wtedy oczywiście piszę testy szczegółowe ponieważ przez API ciężko byłoby pokryć wszystkie przypadki. W większości przypadkach logika nie jest aż tak skomplikowana i testy na poziomie pojedynczych klas są zbyt kosztowne i sprowadzają się do tworzenia bardzo wysokiej liczby mock’ów lub stub’ów.

Innymi słowy, testy nie powinny być powiązane ze szczegółami implementacyjnymi, które mają prawo zmienić się w każdej chwili (refaktoryzacja), a które nie zmieniają zachowania. Jeśli zachowanie pozostaje takie same, wtedy przecież również testy powinny pozostać niezmienione.

Dziś chciałbym pokazać kilka scenariuszy, które według mnie są przykładem złych testów.

O tym jak szczegółowo należy pisać testy, opiszę w następnym poście więc tym dzisiaj nie będę zajmować się.

Jednym z często spotykanych błędów jest testowanie zbyt wielu scenariuszy na raz. Test jednostkowy nie powinien wyglądać na przykład w taki sposób:

// przygotowanie danych
// wykonanie operacji

if(id==1)
{
    Assert.AreEqual(1,result.Count);
}    
else
{
    Assert.AreEqual(2,result.Count);
}

Test nie powinien zawierać żadnej logiki bo co jeśli pomylimy się? Jeśli wykonujemy różne asercje, w zależności od jakiś danych, wtedy oznacza to, że powinniśmy stworzyć drugi, osobny test. Asercje powinny być proste i jasne. Jeśli inny programista zagląda do testów i musi analizować je linia po linii, oznacza to, że  asercje są zbyt skomplikowane. Innymi słowy, żadnych instrukcji warunkowych podczas asercji.

Test powinien być napisany jak skrypt, czyli stanowić dokumentację.  Skrajnie zły przykład to:

[Test]
public void Test()
{
    base.VerifySomething(5,"Hello world");
}

W logice biznesowej często zdarza się, że metoda publiczna wywołuje bazową metodę z jakimiś parametrami, ewentualnie poprzedzając to inną prostą logiką. W testach chcemy mieć jasny skrypt zdarzeń zachodzących po kolei. Musi być wyraźnie widoczne jak dane są przygotowane, wywołane,  a na końcu zweryfikowane. Wywołując jakieś metody bazowe, tak naprawdę dla czytelnika takiego kodu, wygląda to jak czarna skrzynka, a nie dokumentacja, którą testy przecież powinny stanowić.

Nie oznacza to, że musimy duplikować kod we wszystkich testach, które wykorzystują podobne kroki. To naturalne jest, że duża część kodu może być taka sama dla różnych testów. W takich przypadkach, zamiast implementacji jednej, dużej metody, która wykonuje wszystkie kroki, lepie opakować w metody wyłącznie pojedyncze kroki. Podobnie z asercjami, można w końcu skomplikowane asercje  zaimplementować za pomocą metod rozszerzających. Nie powinniśmy jednak kopiować wszystkich asercji do osobnej metody, nawet jak są wykorzystywane w różnych testach. Tak jak podkreślałem wielokrotnie już, test powinien stanowić skrypt opisujący testowany scenariusz.

Nie ma łatwej reguły co powinno trafiać do osobnych metod, a co powinno być bezpośrednio w metodzie testującej. Celem jest stworzenie przejrzystego testu, który można przeczytać i zrozumieć bez skakania do różnych metod w klasie\projekcie. Bardzo kuszące jest zlikwidowanie zduplikowanego kodu (wykorzystywanego w różnych testach) poprzez ekstrakcje go do innej metody, ale trzeba to robić z rozsądkiem. Nie chcemy mieć w końcu w każdym teście czarnych skrzynek w postaci metod typu “PrepareData” czy “InitializeScenarioSteps”. Czasami nawet lepiej pozostawić pewien kod zduplikowany (oczywiście w granicach rozsądku) niż na siłę wszystko automatyzować i wydzielać.

Dzisiaj chciałbym pokazać bardzo fajne narzędzie ułatwiające pisanie testów, szczególnie podczas refaktoryzacji i pracy nad starym kodem.

Dzięki nCrunch jesteśmy w stanie zobaczyć bardzo szybko, które linie kodu są pokryte przez testy. nCrunch wykonuje testy w tle i muszę przyznać, że robi to bardzo szybko. Wygląda na to, że w pełni wykorzystuje możliwości programowania współbieżnego.

Załóżmy, że mamy jakiś kod, który nie ma jeszcze testów (legacy code). W takiej sytuacji, nCrunch zaznaczy wszystkie linie czarnymi kropkami:

Następnie, napiszemy podstawowy test sprawdzający dzielenie:

Zielone kropki w przypadku testów oznaczają, że został on wykonany pomyślnie. Nie musimy ręcznie go uruchamiać, ponieważ nCrunch zrobi to za nas w tle. Działa to na tyle wydajnie, że szybciej jest poczekać aż nCrunch wykona go automatycznie w tle niż uruchamiać test z poziomu Visual Studio. Gdyby test nie udał się, wtedy odpowiednie linie będą zaznaczone na czerwono tzn.:

Przejdźmy teraz do implementacji MathHelper:

Ze screenu widać, że jedna linia nie jest pokryta ponieważ nie dostarczyliśmy na wejście wartości zero. Najeżdżając kursorem na kropki, dostaniemy dodatkowe informacje o pokryciu:

Oprócz graficznego wsparcia, mamy również standardowe tabelki pokrycia, ale to już było dawno osiągalne choćby z poziomu samego Visual Studio.

nCrunch został stworzony jako narzędzie do TDD, ale szczególnie jego zalety zauważam w przypadku pracy ze starym kodem, który nie był napisany w sposób TDD, stąd jego pokrycie może być dość słabe.