Są rzeczy ważne, ważniejsze i testy jednostkowe. No i może kakałko wypadałoby umieścić na końcu listy, przynajmniej zimą. Wracając jednak do testów, uważam je za podstawowe narzędzie do poprawy jakości kodu. Pozwalają nam szybko przetestować, czy nasza twórczość działa poprawnie i (jeśli testy są prawidłowo napisane) zgodnie z założeniami biznesowymi. W dzisiejszym, dość krótkim, artykule chciałbym Wam przedstawić narzędzie Coverlet służące do obliczania pokrycia kodu przez testy jednostkowe. Jest to krótki wstęp do artykułu, który ukaże się w przyszłym tygodniu, gdzie pokaże jak za pomocą dotnet CLI można podpiąć analizę Coverlet do SonarQube.
Instalacja
Rozpoczęcie działania programu wymaga jego instalacji (No s**t Sherlock! ;)) .NET Core ma przyjemne narzędzie do instalacji globalnych paczek, coś w stylu npm i -g. Wystarczy, że przejdziemy do terminalu i wklepiemy:
$ dotnet tool install --global coverlet.console
W tym momencie w konsoli powinno pojawić się nam polecenie Coverlet. Osobiście niezbyt z niego korzystam. Znacznie częściej instaluje paczkę lokalnie, do projektu z testami. Łatwiej mi wtedy dodać krok mierzenia pokrycia kodu do pipeline-ów CI. Takie polecenie wygląda następująco:
$ dotnet add package coverlet.msbuild
Zwróćcie uwagę, że została zmieniona nazwa paczki. Wynika to z faktu, iż bardziej interesuje nas sama integracja z MSBuild-em niż wywoływanie poleceń z konsoli. Dobrze, teraz już możemy korzystać z możliwości Coverlet.
Uruchomienie analizy
Mając zainstalowane wszystkie paczki czas przejść do uruchomienia analizy pokrycia kodu. Czego potrzebujemy? Na pewno przyda się jakiś projekt z testami. Tak się składa, że miałem małą aplikację konsolową, wręcz idealna do tego zadania. Dopisałem kilka testów i możemy uruchamiać. Najprostszy sposób na uruchomienie analizy to dodanie parametru CollectCoverage z wartością true do polecenia uruchomienia testów. Wygląda to wtedy następująco:
$ dotnet test /p:CollectCoverage=true
Jako programiści, chcąc używać tego narzędzia w systemach CI, potrzebujemy więcej niż tylko wyniku w konsoli. Przydałoby się wygenerować i zapisać raport w formacie opencover (ten format jest wspierany przez SonarQube). Dodatkowo nie potrzebujemy analizy namespace-ów xunit.runner, w końcu to kod zewnętrzny.
Do tego musimy użyć trzech parametrów Coverlet: CoverletOutputFormat, CoverletOutput i Exclude
CoverletOutputFormat-> Ustawia w jakim formacie ma zostać wygenerowany wynikCoverletOutput-> Wybiera gdzie ma zostać zapisany raportExclude-> Pozwala na wykluczenie klas i namespasce-ów z raportu
Polecenie z powyższymi parametrami będzie wyglądać następująco:
$ dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover /p:CoverletOutput=./opencover /p:Exclude="[xunit.runner.*]*"
Więcej parametrów możecie znaleźć przy użyciu polecenia Coverlet --help w konsoli (jeżeli zainstalowaliście paczkę coverlet.console) lub w dokumentacji.
Poniżej możecie zobaczyć wynik takiej analizy.
Podsumowanie
Na dziś to tyle, mam nadzieje, że skromny, acz treściwy artykuł wspomoże Was w dalszym rozwoju. Jak już napisałem na początku, w przyszłym tygodniu opiszę jak zintegrować wygenerowany raport z SonarQube.
Do Następnego!
Cześć!