Testing

brian's picture

So just a quickie post. NAnt doesn't play very nicely with the MSBuild task especially with .NET 3.5, so I thought I'd post a snippet from a build file that I think I finally like (and works!).

* project has been renamed [to csharptocsharp] to protect the innocent lame!

<property name="msbuild" value="C:/WINDOWS/Microsoft.NET/Framework/v3.5/MSBuild.exe" />
<target name="compile" description="Compiles using the AutomatedDebug Configuration">
<!-- NAnt doesn't like this part! :( -->
<!--<msbuild project="src\csharptocsharp.com.sln">
<property name="Configuration" value="AutomatedDebug" />
</msbuild>-->
<!-- So we just use an exec task instead!-->
<exec program="${msbuild}">
<arg value="src\csharptocsharp.com.sln" />
<arg value="/v:n" />
<arg value="/p:Configuration=AutomatedDebug" />
<arg value="/p:WarningLevel=0" />
</exec>
</target>

kick it on DotNetKicks.com

brian's picture

So here's a short follow up to a comment from anonymous2 in the Visual Studio automate testing post. Anon2 was right! I totally needed coverage and fxcop to be built into the build process... so here we go with another attempt at using Visual Studio's post-build events to automate testing [and make it even hotter!].

With the suggestion from this comment. All of these items are now fully contained in the project. All tools live in the project's /lib folder and all results live in /reports.

Ahem...

set NCOVER=C:\SVN\TNCMSDemo\trunk\lib\ncover\NCover.Console.exe
set NUNIT=C:\SVN\TNCMSDemo\trunk\lib\nunit\nunit-console.exe
set NUNITXML=C:\SVN\TNCMSDemo\trunk\reports\nunit.xml
set FXCOP=C:\SVN\TNCMSDemo\trunk\lib\fxcop\fxcopcmd.exe

copy /Y "$(ProjectDir)Web.config" "C:\SVN\TNCMSDemo\trunk\TNCMSTest\App.config"

%NCOVER% %NUNIT% /xml %NUNITXML% "C:\SVN\TNCMSDemo\trunk\TNCMSTest\bin\Debug\TNCMSTest.dll" //x "C:\SVN\TNCMSDemo\trunk\reports\Coverage.xml" //l "C:\SVN\TNCMSDemo\trunk\reports\Coverage.log"

%FXCOP% /project:C:\SVN\TNCMSDemo\trunk\tncms.fxcop /out:C:\SVN\TNCMSDemo\trunk\reports\FxCopReport.xml

"C:\SVN\TNCMSDemo\trunk\lib\nunit\nunitresults\nunitresults.exe" %NUNITXML% C:\SVN\TNCMSDemo\trunk\reports\

Now some explanation:
We set some vars because programmers are lazy like efficiency.
set NCOVER=C:\SVN\TNCMSDemo\trunk\lib\ncover\NCover.Console.exe
set NUNIT=C:\SVN\TNCMSDemo\trunk\lib\nunit\nunit-console.exe
set NUNITXML=C:\SVN\TNCMSDemo\trunk\reports\nunit.xml
set FXCOP=C:\SVN\TNCMSDemo\trunk\lib\fxcop\fxcopcmd.exe

We copy a Web.config to an App.config of our test project to do 'expectation' assurance / testing.
copy /Y "$(ProjectDir)Web.config" "C:\SVN\TNCMSDemo\trunk\TNCMSTest\App.config"

Here's where the sauce begins to flow. I call NCover (shorthand as %NCOVER%) which calls NUnit console (%NUNIT%).

%NCOVER% %NUNIT%

I designate a custom-named xml output file for the nunit process with the /xml switch.
/xml %NUNITXML%

Next is the path to the dll to test
"C:\SVN\TNCMSDemo\trunk\TNCMSTest\bin\Debug\TNCMSTest.dll"

The //x switch is for a custom-named coverage xml file (in this case, I want to control the location)
//x "C:\SVN\TNCMSDemo\trunk\reports\Coverage.xml"

The //l switch is for a custom-named coverage log (again, I want to control the final location) [we're almost done!]
//l "C:\SVN\TNCMSDemo\trunk\reports\Coverage.log"

Now I call FxCop's command line utility app.
%FXCOP%

Here is the reference to the .fxcop project file I made with the actual FxCop desktop app
/project:C:\SVN\TNCMSDemo\trunk\tncms.fxcop

And here is where I want its output to go.
/out:C:\SVN\TNCMSDemo\trunk\reports\FxCopReport.xml

Finally, I use NUnitResults to generate a nice html report.
"C:\SVN\TNCMSDemo\trunk\lib\nunit\nunitresults\nunitresults.exe"

%NUNITXML% is the path to the nunit xml file (see above)
%NUNITXML%

And here is the directory that I want it to live.
C:\SVN\TNCMSDemo\trunk\reports\

Now that you have that sorted out, you can spend your time crafting hot c0de.

Stuff you will need to accomplish the above:
NUnit console
NUnitResults
FxCop
NCover console

If you thought that was the opposite of teh suX0r, or something to add/fix/nuke... leave a comment [or kick it]! (or leave one anyway)

kick it on DotNetKicks.com

brian's picture

Whether you're into test driven development (TDD) or test after development (TAD), or you're into having your code get br0xored by not testing (doh!)... unit testing is all over the development world. You're a silly-goose if you haven't heard about it. In any case, using Visual Studio's post-build event process is a nice way of making sure your tests are always executed after a build. Though this isn't news to most developer 'dudes,' it surely made me all hot and steamy when I did it!

To do it you'll need the following:

  • Visual Studio (no duh)
  • Some sort of command line unit test app... like nunit console
  • A new pair of pants after you see how rad this is.

So, you go here:
Visual Studio -> Project Properties -> Build Events

And add this line, pointing nunit-console to the DLL of your project:

"C:\Program Files\nunit\nunit-console.exe" "C:\SVN\Proj\trunk\ProjTestProj\bin\Release\ProjTestProj.dll"

And that's it! Get ready for the hotness!

But wait! There's more!

As an added bonus... I add this line before the line above...

copy /Y "$(ProjectDir)Web.config" "C:\SVN\Proj\trunk\ProjTestProj\App.config"

This enables "Unit testing" (or more like expectation testing) of the Web.config file by copying it over to the Unit Test project as App.config. When this happens, you would be able to talk to it in your Test project via the ConfigurationManager. For example:

Assert.AreEqual("666", ConfigurationManager.AppSettings["SomeImportantNumber"]);

kick it on DotNetKicks.com

Heavy Metal Rock and Roll.

Readers / Stuff

Add to Google

facebook