Microsoft Research opracował ciekawe rozwiązanie automatycznego generowania testów jednostkowych. Artykuł:

http://msdn.microsoft.com/pl-pl/library/pex-i-moles–narzedzia-do-automatycznego-generowania-testow-jednostkowych

IntelliTrace jest doskonałym narzędziem ułatwiającym debuggowanie przez tzw. “time travel”. Umożliwia to podczas debuggowania np. cofnięcie się do poprzedniej linii lub prześledzenie nagranej wcześniej sesji (w przypadku np. awarii systemu). W tym poście jednak nie będziemy zajmować się obsługą tego narzędzia a scenariuszem w którym mamy zainstalowany program na innym komputerze, na którym nie jest dostępny Visual Studio.

Przede wszystkim na dany komputer należy skopiować następujące pliki (wymagane przez IntelliTrace):

1. IntelliTrace.exe
2. IntelliTrace.exe.config
3. Microsoft.VisualStudio.IntelliTrace.dll
4. TraceLogProfiler.dll

Następnie możemy rozpocząć proces nagrywania poprzez następującą komendę:

IntelliTrace.exe launch /cp:collection_plan.xml Test.exe

Test.exe jest aplikacją, którą będziemy debuggować. Parametr launch uruchamia loggera i aplikację, rozpoczynając tym samym zbieranie informacji.

CollectionPlan jest plikiem XML zawierającym konfigurację IntelliTrace, czyli np. informacje o zbieranych zdarzeniach, szczegółowości itp. Najlepiej obejrzeć sobie plik wygenerowany przez Visual Studio i zmodyfikować go do własnych potrzeb (np. ustawić <DeleteLogOnExit>false</DeleteLogOnExit>).

I to wszystko! Po nagraniu sesji można plik nagrań z powrotem skopiować na komputer developera i odtworzyć debuggowanie już z użyciem Visual Studio i wszystkich ułatwień jakie nam oferuje. Naprawdę przydatna opcja gdy aplikacja działa na jednym komputerze a na drugim już nie…

W Visual Studio można stworzyć tzw. Generic Test. Co to takiego? Jest to po prostu wrapper na narzędzie dostarczone przez kogoś innego. Powiedzmy, że do przetestowania jakiegoś modułu wykorzystujemy narzędzie stworzone przez zewnętrzna firmę. Za pomocą Generic Test możemy podpiąć zewnętrzne narzędzie i wykorzystywać zalety testów VS (np. raportowanie). W konfiguracji Generic Test określamy m.in. ścieżkę do zewnętrznego narzędzia, przyjmowane argumenty oraz opcjonalne parametry (zmienne środowiskowe, dodatkowe pliki). Jeśli wywołany plik exe zwróci 0 wtedy test zostanie uznany przez VS jako zaliczony.

Nie będę tłumaczył na polski powyższych nazw bo nie mam pojęcia jak to oficjalnie zostało nazwane. W każdym razie, cechą wspólną powyższych testów jest szybkość i pobieżność – stanowią one wstęp do prawdziwego, gruntowanego testowania. Poniżej kilka najważniejszych cech opisujących smoke test:

1. Zwykle zautomatyzowany – np. w formie testu jednostkowego.
2. Testuje każdą warstwę systemu pobieżnie.
3. Sprawdza czy najważniejsze fragmenty systemu działają, nie wgłębiając się w logikę biznesową.
4. Ma charakter horyzontalny a nie wertykalny – weryfikuje wszystkie aspekty pobieżnie.
5. Smoke test wywodzi się z testowania sprzętu – podłączamy nowe urządzenie i sprawdzamy czy nie… wybuchnie. Jeśli pojawi się dym wtedy wiemy, że coś poszło nie tak:). Nazwa określa po prostu szybkie testy które w jakimś stopniu potrafią sprawdzić czy aplikacja działa.

Z kolei Sanity Test charakteryzuje się:

1. Stanowi podgrupę testów regresyjnych wykonywanych po naprawieniu pewnego błędu – weryfikuje czy po zmianie kodu, aplikacja nadal działa w sposób przewidywalny.
2. Zwykle niezautomatyzowany (chodź z tym można dyskutować…).
3. Należy do tej samej grupy testów co smoke test – weryfikacja pobieżna.
4. Testowanie wertykalne a nie horyzontalne.

Powyższe testy to raczej kwestia nazewnictwa. Wykonywane są wciąż w formie testów jednostkowych lub manualnych. Każdy chyba po kilku zmianach “przeklikowuje” aplikację czyli wykonuje tak naprawdę manualny smoke test:).

W testach jednostkowych czasami warto testować również prywatne metody. Wynika to z zasady atomowości. Prywatne metody z reguły zawierają atomowe operacje, wykorzystywane potem w metodach publicznych. Jednym ze sposóbów jest użycie mechanizmu refleksji. W tym poście zajmiemy jednak się narzędziem publicize.exe, służącym do zmieniania modyfikatorów prywatnych na publiczne. Załóżmy, że mamy taką klasę:

class Klasa
{
   private int _PrywatnePoleA;
   private int _PrywatnePoleB;
   private event EventHandler Zdarzenie;
}

Uruchamiamy Visual Studio Command Prompt i wpisujemy:

publicize.exe NazwaBiblioteki.dll

Program wygeneruje nową bibliotekę, w której prywatne pola (_PrywatnePoleA, _PrywatnePoleB) będą dostępne jako publiczne. Wygenerowana biblioteka (NazwaBiblioteki_Accessor.dll) nazywana jest “Private Accessor”. Po podłączeniu do projektu, możemy przekonać się, że prywatne pola zostały zastąpione publicznymi:

ClassLibrary1.Klasa_Accessor klasa;
klasa._PrywatnePoleA = 3;
klasa._PrywatnePoleB = 6;