Friday, April 08, 2011
 #
 
In a recent project, I decided that I would use NUnit for testing functions during my development. There were a couple of things I learned in using it within Visual Studio 2010.

First, I read that the Nunit.config tags were needed within 2010 - as it defaults to .Net 4. NUnit installs to the "C:\Program Files\Nunit<version>". Within that is the "bin\.Net-2.0 folder. There is a config file "nunit.exe.config" that is used when using the GUI for testing. right after the configuration tag  I read that you need to add:

<startup>
<requiredRunTime version ="4.0.30319"/>
</startup>

I am using Nunit 2.5.9 - and without those tags - it still worked for me.

The other thing I learned was what would normally be an App.Config file needs to be a totally different file. You need to create a config file that matches the NUnit Project file name - and it must be located in the same directory as the NUnit Project file - so the NUnit GUI can find it.

Our project structure has a folder for Dependencies where we store DLLs that get used in the project - but might not have the source in the project. I created my NUnit Project file  in that folder. If that file is called NUnitProjectTests.nunit - there must be a config file called NUnitProjectTests.config - and that is used as your App.Config while running the GUI tests. In my project it is not in the "bin\Debug" folder - it's in a totally different folder.
You just need to remember to set the values in there and make them match your real app.config for your project output.

Friday, April 08, 2011 9:41:45 AM (Eastern Standard Time, UTC-05:00)
 Wednesday, November 05, 2008

I found a link tonight that led to a Codeplex project http://www.codeplex.com/cracknetproject.

From the Codeplex site

Crack.NET is a runtime debugging and scripting tool that gives you access to the internals of a WPF or Windows Forms application running on your computer. If you love Snoop and Mole for Visual Studio, you’ll love Crack.NET, too. Crack.NET allows you to “walk” the managed heap of another .NET application, and inspect all values on all objects/types.

This looks like a good tool in becoming familiar with what is going on in WPF and Winform apps.

 

 

Wednesday, November 05, 2008 10:04:02 PM (Eastern Standard Time, UTC-05:00)