DesignAndCode software development thoughts..

A few years ago, I heard about  a product that was in development called Mole that was used for .Net debugging visualization(now the company is called Moloscope). Today, I came across a "topic category" called "moles" in a question on Stackoverflow- initially I thought this was the same thing- but it is not. Apparently, Microsoft research developed an  Isolation framework that allows test code to create a "detour" - a detour can replace the .Net framework calls with your own delegate - to execute your unit test with - by reworking the IL code for the .Net Framework code. The Microsoft Research group named it Moles. A one letter difference between very different tools.

The Moles Framework was new to me,  and since it was connected to Pex, a "white box" testing tool I heard about back in 2008, - I was very interested in knowing more on this. Code Project has an article on the combination of Pex and Moles usage in testing applications.

In the StackOverflow question I started with, there were links to three training videos on the use of Pex and Moles, delivered by Peli de Halleux in a class in Spain, so it starts in Spanish but the class is in English.  'Video Part 1'(00:58) starts with a software test that requires access to a hard disk - and by the end of the video they have replaced that test disk access with a Moles delegate and even step into the debugger with it. This video used overlays to ensure you had a camera view of the instructor or monitor - even when people were walking in front of a camera - your view is of the subject (some walk throughs do occur) -so it is one of the better live presentation video recordings I have seen. 'Video Part 2' (1:57), and 'Video Part 3'(2:26).

InfoQ has a video presentation entitled "Test First v.Next with Pex and Moles"  presented by David Star (from Pluralsight) given at DevTeach in Belgium during October 2011. In the presentation he introduces Pex, and then the use of Code Contracts which Pex recognizes, and then works in how to use Moles framework. This presentation is a good introduction to the use of all three tools for development work. Mr Star clarifies the framework as not being a "mock" framework.

The combination of the tools should prove useful in the right context. With an end goal of having good tests for your code, and where you need to fake, detour, round some difficult bits that can cause issues.

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.

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.