Na het bepalen van mijn doelen voor 2021 (link) zou ik vandaag (22 februari 2021) aan de slag met de punten die daar staan. Maar eerst de ramen schoongemaakt, de 6 podcasts van Scott Hanselman uitgewerkt die ik tijdens mijn zondag-wandeling van 22.5 kilometer beluisterd heb, 50 bladzijden lezen in mijn bibliotheekboek. Dus ik begin iets later. Maar dat maakt niet uit, want dit punt is niet zo uitgebreid.
In podcast 103 van Scott Hanselman (link) komt code-coverage voorbij. Als je maar 5% van je applicatie test, hoe zeker kun je dan zijn dat bij een aanpassing of een "fix" van een probleem de andere 95% niet "per ongeluk" kapot gaat? Eigenlijk niet, dus inzicht is dan wel fijn. Daar is dus een tool voor, de link bij het artikel van de podcast werkt niet meer. Maar via een "zoek je misschien.. link" kwam ik op deze pagina op docs.microsoft.com.
Daar wordt inderdaad het juiste product besproken. Het artikel is van 23 juli 2019 en begint ermee dat het alleen werkt in de Enterprise Edition. Ik zag echter dat ik ook nog een Github-project genoteerd had: https://github.com/coverlet-coverage/coverlet
Voor mijn eigen projecten gebruik ik de Express Edition van Visual Studio. Ik heb een eigen project geopend, testproject toegevoegd. En daar in de Package Manager Console het statement uitgevoerd wat in het Github-project genoemd wordt:
Install-Package Microsoft.CodeCoverage -Version 16.8.3
Hierna zag ik echter niets gebeuren. Geen extra tabblad of opties. Dus verder gaan doorklikken en uiteindelijk kom ik op deze pagina: https://docs.microsoft.com/en-us/dotnet/core/testing/unit-testing-code-coverage?tabs=windows
Zoals daar staat werkt het voor .NET Core projecten (is is het open-source dus overal te gebruiken). Omdat ik toch nog (te) veel met het .NET Framework werk (en niet met Core/Standard) is dit een mooie gelegenheid om daar een blanco project voor aan te maken en de stappen te volgen die op deze pagina besproken worden.
De stappen staan wel op die pagina, maar hier ook nog even "in het kort", mocht ik later nog wat willen controleren o.i.d., dan kan ik dat snel op deze pagina doen. Let wel op, ik had dit eerst in de Developer Command Prompt van Visual Studio, maar je moet deze acties in Powershell uitvoeren (daar werkt de ls **/*.csproj namelijk).
dotnet new classlib -n Numbers -- bestand class1.cs hernoemen naar PrimeService.cs en vullen met codedotnet new xunit -n XUnit.Coverlet.Collectordotnet new xunit -n XUnit.Coverlet.MSBuild -- testprojecten aanmakendotnet add XUnit.Coverlet.Collector\XUnit.Coverlet.Collector.csproj reference Numbers\Numbers.csprojdotnet add XUnit.Coverlet.MSBuild\XUnit.Coverlet.MSBuild.csproj reference Numbers\Numbers.csproj -- testprojecten koppelen aan het echte projectcd XUnit.Coverlet.MSBuild && dotnet add package coverlet.msbuild && cd .. -- nuget package installeren -- bestandenUnitTest1.cs hernoemen naar PrimeServiceTests.cs en vullen met codedotnet new sln -n XUnit.Coverage -- maak een solution aandotnet sln XUnit.Coverage.sln add (ls **/*.csproj) --in-root -- voeg de projecten toe in de solution -- dit werkt alleen in Powershell dotnet build -- vervolgens gaan we testen: cd XUnit.Coverlet.Collector && dotnet test --collect:"XPlat Code Coverage" -- deze gecombineerde statements werkten alleen in Developer Console. In Powershell dus bovenstaande statements "los" uitgevoerd: cd XUnit.Coverlet.Collector dotnet test --collect:"XPlat Code Coverage" En het andere MSBuild project kun je uitvoeren met: cd XUnit.Coverlet.MSBuild dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura
Bovenstaand scenario op mijn computer uitgewerkt, even wat syntax-problemen bij het uitvoeren in de Developer Command Prompt (en daarna over naar Powershell), er worden inderdaad netjes XML-bestanden aangemaakt met een "code coverage" overzicht.
Als ik binnenkort met een .NET core project aan de slag ga én er een test-project bij heb, zal ik deze stappen ook uitvoeren. Nog mooier is het om het automatisch in je build-scripts mee te nemen. "Vroeger" maakten we geen test-project(en), we bouwden de code, deden onze eigen gebruikerstesten en als dat goed leek te gaan was het "afgerond". Maar zoals de meeste developers wel weten, in 9 van de 10 gevallen komen er toch bugs naar boven die opgelost moeten worden. Of moeten er allemaal nieuwe zaken bij gebouwd worden, waar bij de initiële bouw geen rekening mee gehouden was. Dus iets wat eerst heel overzichtelijk leek wordt steeds groter en groter en uiteindelijk wordt je bijna bang om wijzigingen door te voeren. Dan weet je zeker dat je een test-project moet toevoegen. Doordat je code dan ook testbaar moet zijn, maakt dat je code sowieso al beter. En dan kan dit onderdeel je daarbij ondersteunen om te zien: ik testte niets, ik test nu 80%, is dat voor mij voldoende?