Showing posts with label Unit Testing. Show all posts
Showing posts with label Unit Testing. Show all posts

Wednesday, 3 September 2008

NUnit through Visual Studio

As you may know Visual Studio (VS) has quite nice integration with MSTest projects.  It has a test list editor and view that allow you to see the tests in the solution and choose which to run.  If any fail you can debug through the tests using the VS debugger.

However, as you may have gathered from previous posts we are using NUnit, basically beacause we don't want to buy an extra VS licence for our automated build machine (yes, thanks Microsoft for not including MSTest in the .NET SDK!).

Thankfully, I have disovered a nice add in for VS called NUnitForVS.  This allows NUnit tests to be run and debugged in the same way that MSTest projects are.

Through my install I did discover a couple of issues:

1) You have to manually edit the NUnit Test projects .csproj file to contain a ProjectTypeGuid element.  The one specified on the linked website did not work with VS 2008, so I checked one of my MSTest projects and found the following value which did work...

ProjectTypeGuid {3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}ProjectTypeGuid

2) My Unit Tests didn't appear at first in the Test View.  You have to rebuild the software for it to recalculate the list.

Hint - For ease, I have added a new template project for NUnit tests.   This was created as a Class Library, but I have manually edited the .csproj file to contain the ProjectTypeGuid element I mentioned above. 


Friday, 29 August 2008

NUnit missing assembly reference error

Recently I have been getting a few errors running Nunit on our automatic build server. Nunit is being called through an MSBuild file, which is being called by CruiseControl.NET. The CruiseControl build log has been recording the error messages below:
EventLogListenerTest.cs (6,7): errorCS0246: The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
EventLogListenerTest.cs (18,10): errorCS0246: The type or namespace name 'TestFixtureSetUp' could not be found (are you missing a using directive or an assembly reference?)
EventLogListenerTest.cs (18,10): errorCS0246: The type or namespace name 'TestFixtureSetUpAttribute' could not be found (are you missing a using directive or an assembly reference?)
EventLogListenerTest.cs (25,10): errorCS0246: The type or namespace name 'TestFixtureTearDown' could not be found (are you missing a using directive or an assembly reference?)
EventLogListenerTest.cs (25,10): errorCS0246: The type or namespace name 'TestFixtureTearDownAttribute' could not be found (are you missing a using directive or an assembly reference?)
These errors are only happened when I ran CruiseControl as a service... so I logically assumed that this must be a security issue with the Local service account not being able to see the Nunit assemblies. However, the issue was not resolved by running the service as the logged in user.

The solution I found was to manually add the Nunit.Framework.dll from the Nunit directory in "c:\program files" to the Global Assembly Cache (GAC). This resolved all the missing assembly reference" errors.

Monday, 28 July 2008

Visual Studio 2008 Test List Editor Bug

Monday morning: After another weekend of travelling around the country (this time London) I have returned to work and discovered a juicy bug in Visual Studio 2008. (VS)

I noticed that when I closed my projects and reopened them, all the Unit Test lists disappeared from my Test List! Investigation revealed that VS had actually replaced the vsmdi file (myProject.vsmdi) with a new one (myProject1.vsmdi). To get the original test list back you have to delete this new one and re-add the original one from the project directory.

A temporary work around to get around the issue is to close the Test List Editor prior to closing the solution/project or VS.

I've checked on Microsoft's connect website and this has already been reported. Interestingly enough I came across this post by Aaron Stebner (here!) about best practice when logging a Bug with Microsoft.