recommended approach of adding altcover to test-projects (for ci build only)

[kimpenhaus]

Hey @SteveGilham ,

first of all: thanks for this alternative code coverage approach 🙏🏼 we are working with a large code base with lots of unit tests and were using coverlet with cobertura format before. executing the tests and measuring the code coverage took us really long (up to 15 minutes) - switching to altcover boosts up to 60% and we are now running in under 5 minutes - that's totally amazing - thanks!

what we want to do is: measure code coverage only during our ci build

what is not really clear to us is - which assemblies are instrumented and when. the docs says:

Rather than working by hooking the .net profiling API at run-time, it works by weaving the same sort of extra IL into the assemblies of interest ahead of execution

but what are those assemblies of interest? sorry if this sounds like or is a stupid question :) but what we did now is to add altcover into all our test projects by default. so it is there evene when running locally builds and tests as well as when running ci build or even when running release builds and deployments...

test-project.csproj:

<PackageReference Include="altcover" />

---

we tried to add altcover during ci build only with dotnet custom (add package) command but that failed with the central package mamanagement we have:

task:

      - task: DotNetCoreCLI@2
        displayName: 'add altcover'
        enabled: True
        inputs:
            command: 'custom'
            projects: '**/*Tests.csproj'
            custom: 'add'
            arguments: 'package altcover'

error during dotnet restore:

NU1008: Projects that use central package version management should not define the version on the PackageReference items but on the PackageVersion items: altcover.

---

only during ci build the msbuild parameter is set: /p:AltCover=true on any other build it is not explicitly set.

we are now wondering if this is an approach to go or if that might have an impact on our releases (the deployed assemblies) as they might get instrumented (by just having the altcover package added). or if there is any better approach to only have it instrumented during ci build. we actually would love to do the dotnet add package approach as any newly added test project will get automatically a reference to altcover - maybe any one else has a solution for the cpm error?

thanks for helping and again thanks for the project and your time and effort you've put into!

[SteveGilham]

The NU1008 error is a consequence of dotnet add package blindly inserting a versioned reference entry into the project, and not doing anything fancy by way of looking for an overriding central package file. If you add altcover to the central package version management file, and then only add it to the test projects on the CI machine ahead of testing, then it inserts an unversioned package reference that won't provoke that error, but will be inert otherwise

The "assemblies of interest" are the ones in the specified input directory that pass the supplied filters when the command line tool/MSBuild task/API call is invoked; with no filters meaning "all of them". In the case of the integration with dotnet test, the input directory is hardcoded as the project build output directory, and the filters are those passed in the rest of the command line as /p:AltCoverXxx=... parameters. Otherwise the input directory can be specified as need.

When the instrumentation process is run on a build machine, where the source is available, then the best first filter is using the /p:AltCoverLocalSource=true flag (or appropriate equivalent), so as to exclude all third-party code; this can be refined down from there with the other filter parameters. The --localSource behaviour is not the default for historical reasons (mainly to do with the original version being used for operational testing on machines other than the build machine).

[kimpenhaus]

Thanks for your quick reply and your detailed explanation - I was indeed able to get dotnet add working with the cpm approach - that's really cool 🎉