There are no bugs in the //a switch I am aware of - curious by what you think is a problem? By adding //a you are saying you only want Core output without your Test.dll unit test coverage information.
Also you talk about having a problem with violating your first objective - do you want to clarify?
If it is to do with how you added to your PATH variable - that wasn't needed provided you fully qualify the paths to NUnit/NCover with relative or absolute paths. Depending on which directory you are running in compared to your executables etc you might want to make use of the //w switch to set the working directory. Certainly on our build server we only use relative paths to our tool folders etc - although often in the NAnt script we convert to an absolute path dynamically.
Feel free to drop me an e-mail if I havent made sense...
5:50 AM
Following up on my previous post, I'm continuing to set up code coverage in my .NET 2.0 project with some specific criteria. Kudos to Grant Drake (aka Kiwidude) who is very committed to the cause. I spent some time on his site last night, pouring over some of his FAQ. He left a comment on my blog earlier, citing an FAQ that I missed on his site. Plus he recommended version 1.5.4 of NCover instead of the latest 1.5.5beta. Good stuff! So to follow through on my previous post. The first thing I did was move my test namespace and their classes into a separate ClassLibrary. This included all the standard stuff: remove the reference of NUnit from the Core library add an NUnit reference to the Test library. add a Core Library reference to the Test project. After a quick compile, I dropped down to a command prompt and executed the same statement, except this time I had to specify the name of the Test harness assembly: ncover.console nunit-console Test.dll //a Core
This worked and ...satisifies my second objective! The added bonus is now the coverage report only contains information about the Core namespace. This is great, but as an aside, since nothing has changed in the code I wonder if this is a bug in the "//a" switch? Update: The //a switch is for assemblies without their extensions, not namespaces.
As a further refinement, I can begin to take advantage of NUnit's Project capabilities. This enhancement simplifies things greatly. It allows me to:
test/cover multiple assemblies at a time
shield my build script from having any knowledge about the test harness configuration.
specify where to locate the configuration file (this should solve my third objective)
To create the Nunit project file:
open the NUnit-Gui and choose "New Project". I like to save the nunit file at the root of my solution.
add in the assemblies that contain your test fixtures. In my case, I have to specify the relative path to my Test Harness: /Test/bin/Debug/Test.dll
As an NUnit project file is simply an xml file, my nunit project file contains the following:
<NUnitProject>
<Settings activeconfig="Debug" />
<Config name="Debug" binpathtype="Auto">
<assembly path="Test\bin\Debug\Test.dll" />
</Config>
</NUnitProject>
With this in place, I can now generate my coverage report at the command line with the following statement:
ncover.console nunit-console TestProj.nunit //a Core
So far, this pretty good. The second objective was fairly easy, and although I've violated my first objective, Kiwidude has suggested this might be something I could correct with part of the build script, so I'll get to that soon enough.
Tomorrow, I'll tackle my third objective of being able to resolve configuration settings.
"NCover Setup - Part II"
1 Comment -
There are no bugs in the //a switch I am aware of - curious by what you think is a problem? By adding //a you are saying you only want Core output without your Test.dll unit test coverage information.
Also you talk about having a problem with violating your first objective - do you want to clarify?
If it is to do with how you added to your PATH variable - that wasn't needed provided you fully qualify the paths to NUnit/NCover with relative or absolute paths. Depending on which directory you are running in compared to your executables etc you might want to make use of the //w switch to set the working directory. Certainly on our build server we only use relative paths to our tool folders etc - although often in the NAnt script we convert to an absolute path dynamically.
Feel free to drop me an e-mail if I havent made sense...
5:50 AM