dotCover Console Runner Enhancements
I’ve previously blogged about the possibilities of running code coverage using the dotCover console runner. You can find the Simple Coverage post here and the more Advanced post here. In dotcover 1.1.1 we made some changes to the console runner to facilitate the process even more.
Command Line Arguments
Previous versions of dotCover required that you specify the configuration parameters in an XML file. In dotCover 1.1.1, we now give you the possibility of defining these values directly on the command line in addition to XML Files. The way in which it works is similar to that of MSBuild, that is, you can define or override definitions in the XML file by passing them as arguments on the command line. For instance, take the following configuration file:
If we want to override the Output , we could run this from the command line by passing in the Output folder argument:
dotCover cover coverage.xml /Output=new_output.dcvr
We can do this with any command (cover, report, merge, analyze, etc.) and with any parameter. Parameter names match one-to-one with the element names specified in the XML. As such, to override the <TargetExecutable> element, we would use /TargetExecutable=…., providing us with the flexibility of having a single configuration file and allowing certain parameters to be overridden when required.
A new parameter is available in the cover and analyse command which is InheritConsole. What this does is inherit the console output of the target executable. This is useful for instance in passing messages to TeamCity log output (if for some reason you do not want to use the built-in dotCover in TeamCity). By default it is True.
Support for relative paths
One of dotCover’s earlier shortcomings was the inability to provide support for relative paths in configuration files. This has now been solved in version 1.1.1 also, providing the ability to define relative paths, both in the XML as well as command line arguments.
Relative paths defined in the XML are relative to the location of the XML file. Relative paths defined as command line arguments are relative to the location of the console runner working directory.
Coverage Result Descriptors
In earlier versions of the console runner, dotCover would produce what’s called Result Descriptors, which were index of snapshots. These files were normally required in an intermediate step for merging output of different coverage runs (see Advanced Coverage post for more details). This has also changed. Coverage now produces snapshots directly. This allows the generated files to be opened directly in Visual Studio using the Open Coverage Snapshot entry in the dotCover menu.
For backwards compatibility, intermediate index files are still supported, albeit new coverage calls will no longer generate these.
dotCover 1.1.1 is available for download here.
Subscribe to Blog updates
Thanks, we've got you!
Eager, Lazy and Explicit Loading with Entity Framework Core
Entity Framework Core (EF Core) supports a number of ways to load related data. There’s eager loading, lazy loading, and explicit loading. Each of these approaches have their own advantages and drawbacks. In this post, let’s have a quick look at each of these ways to load data for navigational prope…
OSS Power-Ups: bUnit – Webinar Recording
The recording of our webinar, OSS Power-Ups: bUnit, with Egil Hansen and Steven Giesel, is available. This was the twelfth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webi…
Accelerating Your Testing Workflow with Unit Test Creation and Navigation
Unit tests play an important role in our daily development workflow. They help us ensure our codebase's correctness when writing new functionality or performing refactorings to improve readability and maintainability. In the process, we often create new test files that accompany the p…
Introducing Predictive Debugging: A Game-Changing Look into the Future
With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've always strived to improve the art of debugging. Besides the more standard things you expect from a de…