WinUnit zintegrowany z TFS 2010 (Native C++)

Mimo, że Visual Studio znacząco poprawiono w kontekście programisty C++ to wciąż jednak C++ należy rozdzielić na Native i Managed.

Managed C++ dysponuje tymi samymi narzędziami do unit testów jak świat .NET Framework. Native C++ nie ma nic. Rozwiązaniem tego problemu zajęła się pewna miła programistka z Microsoftu i tak powstał WinUnit: https://winunit.codeplex.com/

Bardzo przyjemny i nieinwazyjny dodatek do naszych projektów. Wciąż wymaga od programisty dużej pracy konfiguracyjnej jeśli chcielibyśmy dobrze ten framework wykorzystać w naszym IDE.

Ja osobiście dla elastyczności podjąłem się wyzwania i skonfigurowałem sobie do projektu testowego odpowiednie nmake. Najprostszy scenariusz u mnie to wpis analogiczny do poniższego:

runtests: clean all
        -@echo [Tests built. Execution started:]
        -@winunit $(OUTDIR)\fs_tests.dll
        -@echo [Done]

Gdzie uruchomienie z wiersza polecen: nmake /f makefile runtests dało mi taki wynik:

[Tests built Execution started:]
Processing [fs_tests.dll]...
(IsoVolumeStructures)
[fs_tests.dll] SUCCEEDED.  Tests run: 1; Failures: 0.

All tests passed.
Tests run: 1; Failed: 0.
[Done]

Winunit.exe zwraca 0 gdy nie ma problemu i inne wartości gdy testy nie wyjdą lub jest problem po stronie hosta. To się da na poziomie nmake’a i nie tylko ładnie oskryptować. Tutaj nie chciałbym narzucać powrotu do plików make jako jedynej drogi. Natomiast ja ten kierunek pociągnąłem dalej ze względu na integrację z TFS 2010.

Podpięcie projektu Nmake pod MSBuild jest trywialne. Wystarczy takowy utworzyć, utworzyć plik makefile i zgodnie z jego konstrukcją podpiąć go pod konfiguracje naszego projektu:

Configuracja Debug czy Release może się różnić tylko przekazaniem odpowiedniej definicji preprocesora. Z testami można stworzyć po prostu osobną konfiguracje, która właśnie zamiast all, rebuild czy clean uruchomi pozycję runtests. Wszystko działa, tylko wymaga od nas trochę manualnej pracy lub może zainspirować do napisania lub poszukania addin’a, który wspiera WinUnit i CMake do automatycznej konfiguracji naszego projektu.
Wierzę, że wasza ulubiona wyszukiwarka dostarczy nawet więcej pomysłów.

Teraz jeśli chciałbym takie testy zautomatyzować na serwerze buildów to niestety jest trochę zabawy. Jak przyjrzymy się definicji konstrukcja testów wygląda następująco:

W najprostszym przypakdu jak widać TFS szuka plików Dll mających test w nazwie, to możemy dostosować do naszego nazewnictwa.

W procesie możemy też odszukać taki element:

Rozwinięcie zaznaczonego pola pozwoli nam podejrzeć jak TFS za pomocą MSTest automatyzuje wykonanie testów w komponentach .NET Framework. Na potrzeby Native C++ musimy to zmodyfikować, aby nasza Dll’ka uruchamiana była przez WinUnit.Exe a nie przez MSTest.exe.

Standardowa konfiguracja oczywiście spróbuje wykonać testy, ale bez modyfikacji spodziewałbym się poniższego wyniku:

1 error(s), 1 warning(s)
TFB210610: 'MSTest.exe' returned an unexpected exit code. Expected '0'; (…) The module was expected to contain an assembly manifest.

Jak zintegrować WinUnit z tym przykładem szablonu builda z poprawnym wychwyceniem błędów w testach oraz na przykład logowaniem? To w kontynuacji tego wpisu niebawem. Samo pozostawienie was w tym miejscu jednak powinno dostarczyć inspiracji do samodzielnych prób.