Some may not be aware of a latent and powerful feature of NCover...the ability to save and reuse coverage configurations. These files are XML scripts containing the settings used for obtaining coverage data as well as producing reports on that coverage. Config files can be written by NCover using an existing setup, or hand-scripted from scratch. Configuration files are especially helpful in any of the following scenarios:

Use Cases

1. Automate build processes – Developers / Testers: When testing from the desktop, you can still integrate NCover into a build / test agent while keeping the arguments to NCover separate from the agent script itself. Developers familiar with NCover will find this very handy as they (1) won’t have to learn how to integrate NCover-specific arguments into any build script, (2) can expect fewer bugs in the build script since fewer ancillary items (e.g., conditionals) need to be reconfigured, and (3) can quickly swap arguments in the file (or entire configurations!) to gain the desired coverage metrics. Want to template your coverage? Not a problem.
2. Communicate project-specific testing standards– QA / Dev Managers: Managers have a hard enough time getting their own work done, especially when they have large teams across several time zones. Why should their developers / testers have to “waste” time learning another product? One or a few people should be able to take responsibility for organizing coverage. Go configuration files! Once the template coverage is written (e.g., for a build server), it can be handed to all developers / testers. This includes the ability for managers to enforce coverage standards that must be met before code is committed to source and ships to the customer. Let coverage standards spillover to the entire team on their desktops from a single template. Even share settings with outsourced teams. It’s a clear win.
3. Supervision of build server – Build Managers: The last thing a build manager wants is someone inexperienced meddling with configurations, especially since it’s their problem when something goes wrong. For those working within an agile environment, there is no room for error when it comes to builds. You’ll get 2 for 1 with configuration files. Project managers and their developers assume responsibility for making changes to their desired NCover setup; coverage changes flow in seamlessly without affecting your build script.

How It Works

NCover Console

</li>

Creating a config file is simple.

There are even several ways to do it. Choose the one that best suits your needs.

1. From the command line. Provide your regular NCover settings along with the following parameter, for example: NCover.Console.exe C:\Program Files\NUnit\NUnitConsole.exe /test args //cs [path to setting file, e.g., "C:\dev\saved\coveragesettingsfile.xml"]

<li>From the NCover Explorer. After you set up your coverage settings with the GUI, find and click the “Script Helper” button at the top menu bar. Click the “NCover Settings File” option. Copy / Paste what you see. You’re done!
</li>

<li>Hand-script a file. If you’re new to NCover and don’t want to learn the command-line flags, simply write your own XML configuration file and don’t worry about a messy prompt. Start scripting your config right away by using the NCover settings tags. The script begins and ends with the &lt;CoverageConfig&gt; tag:<br/><br/>

   &lt;CoverageConfig version=&quot;3.3.4&quot;&gt;
  [coverage config settings]
    &lt;/CoverageConfig&gt;


</li>

Everything in between (i.e., the config settings) can be found here, along with an example here.

NOTE: If you’re running coverage from NCover Explorer, save and use a project settings file instead, which will contain the same information as the settings file and can be shared with other developers. Project Actions > Save Project.

Using a config file is even easier.

We’re using the config file from the command line. It’s ridiculously simple. Supply the path to the config file in your call to NCover, like so:

NCover.Console.exe //cr "C:\dev\saved\settingsfile.xml"

That’s it. Your coverage will run and you’ll have results. Load them into NCover Explorer, or go ahead an create reports using a report configuration file.

NCover Reporting

Creating a config file.

There are two ways.

1. From the command line. Provide your regular NCover Reporting settings along with the following parameter //cs [path to setting file, e.g., "C:\dev\saved\reportsettingsfile.xml"]
2. Hand-script a file. If you’re new to NCover and don’t want to learn the command-line flags, simply write your own XML report configuration file and don’t worry about a messy prompt. Start scripting your config right away by using the NCover settings tags. The script begins and ends with the <CoverageReportSetting> tag:
   
   

       <CoverageReportSetting version="3">
     [report config settings]
       </CoverageReportSetting>
   
   </li>
   

Everything in between (i.e., the report config settings) can be found here, along with an example here.

Using a report config file.

Again, from the command line it’s ridiculously simple. Supply the path to the config file in your call to NCover, like so:

NCover.Reporting.exe //cr "C:\dev\saved\report settingsfile.xml"

That’s it. Your coverage will run and you’ll have your report results.

For a fast, easy, and error-free way of constructing your build and test setups, try using configuration files. Just another way NCover is keeping you covered.