Skip to content

Modes of Operation

Jump to bottom
Steve Gilham edited this page Jul 23, 2018 · 18 revisions

AltCover can be used in a variety of ways, from being almost like the original NCover or current OpenCover, where everything is done all in one, to a complete separation of the stages of instrumentation, testing and then reporting.

Contents

This is a non-exhaustive list of combinations

In the following, when I say altcover, that will mean either <path to>/AltCover.exe or dotnet <path to>/AltCover.dll unless explicitly specified otherwise.

Instrument and test now, classic mode

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover, with the test command line being specified after a -- to execute the tests on the assemblies in the new location, and rely on the ProcessExit handler to write from memory into the XML file.

This is closest in style to running with OpenCover or the old NCover, and is sufficient for moderately large coverage sets in the full .net framework, where the handler has a couple of seconds to work.

Disadvantages

  • doesn't work well for dotnet because the exit handler has much less time to operate
  • doesn't work at all for dotnet test because the instrumented assemblies are somewhere else
  • only a subset of OpenCover format (sufficient for use with coveralls.io and ReportGenerator) is produced

Instrument now, test later, classic mode

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover
  2. Execute the tests on the assemblies in the new location, and rely on the ProcessExit handler to write from memory into the XML file.

This is sufficient for moderately large coverage sets in the full .net framework, where the handler has a couple of seconds to work

Disadvantages

  • doesn't work well for dotnet because the exit handler has much less time to operate
  • sort-of works for dotnet test because the instrumented assemblies can be copied back into place for testing as a separate manual step
  • only a subset of OpenCover format (sufficient for use with coveralls.io and ReportGenerator) is produced

Instrument and test now, runner mode

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover, plus any of [--single] [--linecover|branchcover]; then specify altcover runner after a -- with the test command line being specified after yet another -- to execute the tests on the assemblies in the new location.

This is close in style to running with OpenCover or the old NCover, and will produce all the supported OpenCover format output

Disadvantages

  • doesn't work at all for dotnet test because the instrumented assemblies are somewhere else
  • cumbersome command line

Instrument in place and test now, runner mode

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover, plus any of [--single] [--linecover|branchcover], also specifying --inplace; then specify altcover runner after a -- with the test command line being specified after yet another -- to execute the tests on the assemblies in the built location.

This is close in style to running with OpenCover or the old NCover, and will produce all the supported OpenCover format output

Disadvantages

  • your build artifacts are saved off, so many not be where your build pipeline wants them
  • cumbersome command line

Instrument now, test later, runner mode

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover, plus any of [--single] [--linecover|branchcover]
  2. Run altcover runner to generate the XML report with the test command arguments being specified after a -- to execute the tests on the assemblies in the built location.

With --inplace as part of step 1, this will work with dotnet test

Disadvantages

  • With --inplace your build artifacts are saved off, so many not be where your build pipeline wants them

Instrument now, test later, collect coverage after that

  1. Run altcover to instrument your binaries, using any of the options up to and including --opencover, plus any of [--single] [--linecover|branchcover], also specifying --save
  2. Execute the tests on the assemblies in the new location.
  3. Run altcover runner --collect -r <path to instrumented folder> to generate the XML report

This is the style of operation of coverlet; and with --inplace as part of step 1, this will work with dotnet test in exactly the same way.

Disadvantages

  • multiple steps
  • With --inplace your build artifacts are saved off, so many not be where your build pipeline wants them
Clone this wiki locally