Ungrouped Files

Let’s assume that we have a Default.js file that we want to nest under Default.aspx.  To edit the project file I usually use the Edit Project File option included with the PowerCommands extension to streamline the Unload Project and Edit [project].csproj options.  Once the project file is open in the code editor we need to find Default.js.  Because Default.js is simply included content it will be in a <content> element like the following:

<Content Include="Default.js" />

Once we’ve located the element we need to insert a child DependentUpon element to identify Default.aspx its parent. You’ll probably see plenty of examples in the project file but our finished XML should look like this:

<Content Include="Default.js">
	<DependentUpon>Default.aspx</DependentUpon>
</Content>

Note: Check the Common MSBuild Project Items documentation on MSDN to see which elements DependentUpon can be applied to.

Grouped Files

With the changes made, save the file and reload the project in the IDE. When the project loads Default.js should no longer appear in the main tree but instead be nested under Default.aspx.

If you’re not comfortable editing the project file directly there are some extensions that can streamline this process:

• NestIn
• VSCommands 2010

I haven’t tried either extension but they’re both highly rated in the gallery.  If you know of any others let me know and I’ll add them to the list.

The Journey

When I first looked at JustDecompile last May (v2011.1.516.2) I had really high hopes for it but back then its output was far from acceptable.  Many of my tests resulted in code that in no way resembled the original source and more often than not the result wasn’t even valid C#.  To top it off, the application crashed frequently in easily reproducible ways.  Given what I observed I had no choice but to call it unusable.  That said, it was a beta so I provided some feedback to the team and moved on.

My second look was in September (v2011.1.829.2).  The team had been working on fixing defects and I’d seen several notices that the issues I’d reported were either fixed or being fixed.  This seemed like as good of a time as any to give it another chance.  The first thing I noticed was that the application no longer crashed with the predictability I’d noticed in May.  When I reran my original tests I found that although the code it generated had certainly improved (sometimes to the point of being almost identical to the original source) it still had a number of issues that ultimately left me saying it still wasn’t a viable alternative to the other solutions already available.

For this review I’m using version 2012.1.214.2.  When I read about some of the new features in this release I was pretty surprised to see that Telerik had completely rebuilt the decompilation engine.  For consistency across all three reviews I’ll be sticking with my original series of tests so we’ll see how well the new version fares.

User Interface

I didn’t notice many changes in the UI from the last review.  From what I remember, most everything is in the same place.  The stand-out feature here has to be the Create Project button.

Create Project (also accessible from a context menu) lets us create a new Visual Studio project from a decompiled assembly.  For my simple project I found that although the formatting left something to be desired the generated project was adequate.  I did have to remove the generated _Module_.cs file from the project to get it to compile but otherwise it worked fine.  I can see this being a useful tool for recovering lost code.

Note: Create Project only supports creating projects in C#.  If Visual Basic or IL are selected the button will be disabled.

Multiple Node Selections

I found navigating the assembly panel a but frustrating due to some inconsistencies.  For example, double-clicking will expand or collapse  assembly and namespace nodes  but not individual types.  I also somehow managed to get multiple nodes to appear as selected.  Sometimes collapsing the parent node would clear the selection, other times it wouldn’t.  At one point I even managed to crash JustDecompile just clicking around in the assembly panel but I couldn’t reproduce it.

Code Tests

As I mentioned earlier, this version has a completely rewritten decompilation engine.  Decompilation had come a long way between my last two looks so I was really interested in whether the new engine closed the gap between some of the competing products.  I have to say that this version surprised me a bit.

First, it got most of the decompilations correct – including the conditional operator tests that it choked on before.  What surprised me even more though was some of the code it produced.  The code wasn’t necessarily wrong per se, just…unusual.  Let’s take a look.

Just like before we’ll start with the switch statements.  I’ll be pointing out some of the oddities as we encounter them.  Also assume the following enumeration for all code samples:

public enum SampleEnum
{
	Unknown,
	Item1,
	Item2
}

Switch Statements

The last version I looked at did really well with the switch statements.  It had really come a long way from including MSIL labels and misplacing case bodies.  Although I’m pleased to report that the released version also handles each test correctly I think in some cases quality of the emitted code has taken a step backwards. Take the first test as an example.

In this test I simply return a string from each case:

public string SampleMethod(SampleEnum enumValue)
{
	switch (enumValue)
	{
		case SampleEnum.Item1:
			return "Item 1";

		case SampleEnum.Item2:
			return "Item 2";

		case SampleEnum.Unknown:
			return "Unknown";
	}

	return String.Empty;
}

JustDecompile produces code that is functionally equivalent but introduces a default case:

public string SampleMethod(SampleEnum enumValue)
{
	string empty;
	SampleEnum sampleEnum = enumValue;
	switch (sampleEnum)
	{
		case SampleEnum.Unknown:
		{
			empty = "Unknown";
			break;
		}
		case SampleEnum.Item1:
		{
			empty = "Item 1";
			break;
		}
		case SampleEnum.Item2:
		{
			empty = "Item 2";
			break;
		}
		default:
		{
			empty = string.Empty;
			break;
		}
	}
	return empty;
}

Interestingly, this code from JustDecompile is almost identical to what ILSpy produces. I’m guessing that’s not coincidental since they’re both based on Cecil. Notice I said that the output is almost identical to what ILSpy produces though. The one thing that JustDecompile’s output has that ILSpy’s doesn’t is line 4 – SampleEnum sampleEnum = enumValue;. Again, it’s not necessarily wrong, I don’t understand why it’s there.

The second switch test by adding a variable to store the string from each case rather than returning the string:

public string SampleMethod(SampleEnum enumValue)
{
	var val = String.Empty;

	switch (enumValue)
	{
		case SampleEnum.Item1:
			val = "Item 1";
			break;

		case SampleEnum.Item2:
			val = "Item 2";
			break;

		case SampleEnum.Unknown:
			val = "Unknown";
			break;
	}

	return val;
}

Again, JustDecompile’s result is acceptable:

public string SampleMethod(SampleEnum enumValue)
{
	string val = string.Empty;
	SampleEnum sampleEnum = enumValue;
	switch (sampleEnum)
	{
		case SampleEnum.Unknown:
		{
			val = "Unknown";
			break;
		}
		case SampleEnum.Item1:
		{
			val = "Item 1";
			break;
		}
		case SampleEnum.Item2:
		{
			val = "Item 2";
			break;
		}
	}
	string str = val;
	return str;
}

This decompilation is also functionally correct but this time not only do we have the extra enum declaration and assignment, we also have an extra string declaration and assignment. These variables weren’t present the last time I tried JustDecompile and they’re not present in ILSpy’s output either. They’re unnecessary and I’m not sure where they’re coming from. We see this pattern repeat for the next two tests.

Switch with default test:

public string SampleMethod(SampleEnum enumValue)
{
	var val = String.Empty;

	switch (enumValue)
	{
		case SampleEnum.Item1:
			val = "Item 1";
			break;

		case SampleEnum.Item2:
			val = "Item 2";
			break;

		default:
			val = "Unknown";
			break;
	}

	return val;
}

JustDecompile Result:

public string SampleMethod(SampleEnum enumValue)
{
	string val = string.Empty;
	SampleEnum sampleEnum = enumValue;
	switch (sampleEnum)
	{
		case SampleEnum.Item1:
		{
			val = "Item 1";
			break;
		}
		case SampleEnum.Item2:
		{
			val = "Item 2";
			break;
		}
		default:
		{
			val = "Unknown";
			break;
		}
	}
	string str = val;
	return str;
}

Switch with different default case body:

public string SampleMethod(SampleEnum enumValue)
{
	var val = String.Empty;

	switch (enumValue)
	{
		case SampleEnum.Item1:
			val = "Item 1";
			break;

		case SampleEnum.Item2:
			val = "Item 2";
			break;

		default:
			Console.WriteLine("Unknown");
			break;
	}

	return val;
}

JustDecompile Result:

public string SampleMethod(SampleEnum enumValue)
{
	string val = string.Empty;
	SampleEnum sampleEnum = enumValue;
	switch (sampleEnum)
	{
		case SampleEnum.Item1:
		{
			val = "Item 1";
			break;
		}
		case SampleEnum.Item2:
		{
			val = "Item 2";
			break;
		}
		default:
		{
			Console.WriteLine("Unknown");
			break;
		}
	}
	string str = val;
	return str;
}

Despite the extraneous variables the generated code is doing the right thing.

Conditional Operator

Saying JustDecompile has failed miserably on the conditional operator would be too generous. Before looking at what this version generates let’s review where we’re coming from.

The first test is a simple conditional check against a variable:

public void SampleMethod(int arg)
{
	var isEven = arg % 2 == 0;
	var val = isEven ? SampleEnum.Item1 : SampleEnum.Item2;
}

The last time I used JustDecompile it produced the following:

public void SampleMethod(int arg)
{
	bool isEven = arg % 2 == 0;
	SampleEnum val = isEven || SampleEnum.Item2;
}

As you can see, it got the variable assignment correct but that was about it. The code it generated wouldn’t even compile. This time around though I was surprised in more ways than one.

First, the team has taken a completely different approach by emitting an if/else rather than a conditional operator. This approach deviates significantly even from that ILSpy (which I noted in the last review was actually worse than what JustDecompile did). Furthermore, the code is actually, (finally!) functionally equivalent!

public void SampleMethod(int arg)
{
	byte num;
	bool isEven = arg % 2 == 0;
	if (isEven)
	{
		num = 1;
	}
	else
	{
		num = 2;
	}
	SampleEnum val = (SampleEnum)num;
}

It may not use a conditional operator but the result is the same.

The other test eliminated the isEven variable to flatten the expression:

public void SampleMethod(int arg)
{
	var val = arg % 2 == 0 ? SampleEnum.Item1 : SampleEnum.Item2;
}

JustDecompile also got it right too!

public void SampleMethod(int arg)
{
	byte num;
	if (arg % 2 == 0)
	{
		num = 1;
	}
	else
	{
		num = 2;
	}
	SampleEnum val = (SampleEnum)num;
}

As you can see, JustDecompile has come a long way when it comes to handling conditional operators.

Other Tests

Just as before I ran some older production code through JustDecompile. Although some of the code it produced left me scratching my head a bit (for the same reasons described above) JustDecompile performed much better this time around.

The first method I retested was my old IsNull method I wrote to check if a value in a DataRow was null before I knew about DataRow.IsNull:

public static bool IsNull(object value)
{
	return (value == null || value == DBNull.Value || value.ToString().Length == 0);
}

This time JustDecompile got it right. Of course, the generated code doesn’t look anything like the original and it introduces a really, really poorly named variable but at least the result is the same.

public static bool IsNull(object value)
{
	bool length;
	if (value == null || value == DBNull.Value)
	{
		length = true;
	}
	else
	{
		length = value.ToString().Length == 0;
	}
	bool flag = length;
	return flag;
}

Note: ILSpy’s output matches the original source almost exactly.

The other method I tested has had some serious problems in the past. For example, case blocks were mismatched or intermixed, and the code included MSIL variable names. The decompilation of that method still isn’t perfect but it seems to fail in the same ways as ILSpy. For instance, somewhere in the process an enumeration value initialized to 24 is misrepresented as 25. ILSpy handles this a little better since it tries to cast 25 to the enum but JustDecompile doesn’t.

The Bottom Line

I’ll readily admit that after having seen JustDecompile fail so miserably in the past I didn’t have very high expectations for this release. I’ve never expected a decompilation tool to generate code that matches all of my code verbatim (especially when considering any compiler optimizations) but in the past JustDecompile has generated code that in no way represented the original source. After seeing how well the rebuilt decompilation engine handled these tests I have to say that I’m impressed with how far the tool has come since I first looked at it.

Truth be told though, despite the improvements JustDecompile still feels a bit rough around the edges. As I said, I still managed to crash it once and some of the generated code is a bit questionable.  Overall though, I think it now has it’s place in the toolkit if only for getting a second opinion about how an assembly works.

As a final note, I recently learned about dotPeek, a free decompilation tool from JetBrains. I ran all of my tests against the version 1.0.0.7999 (early access program) and it handled them all perfectly. If you’re still mad at Red Gate and/or are looking for other decompilers, dotPeek looks like it’ll be a very good alternative.

I found a Stack Overflow question about this that pointed to Json.NET as a possible culprit.  Sure enough, the source of the exception was Newtonsoft.Json.  It seems that Visual Studio Ultimate’s IntelliTrace didn’t like something Json.NET was doing and would throw that exception.  The issue is said to be resolved as of release 6 but I haven’t upgraded the assembly yet.

For the time being I’ve added a rule to exclude *Newtonsoft.* from the IntelliTrace modules list as recommended by in the Stack Overflow answer.  Since excluding the assembly I haven’t seen the problem again.

Michael Feathers defines Legacy Code as any code that doesn’t have automated tests, and you agree that automated tests are an important facet of successful software development. Then it happens – you get your next assignment, and it’s your worst nightmare! You have to maintain and enhance a large application that has no tests in place, and there are parts that are just plain scary. Where do you start? Traditional Test Driven Development techniques don’t typically work, since they focus on an inside-out development paradigm.

I will show you the patterns and practices that will help you turn the scary big ball of mud into a tested code base.

I’m excited to have Phil back.  I’ve heard him speak many times and have always found his talks both informative and entertaining.

This month we’re meeting in the 2nd floor conference room at 900 E. 96th Street.  Registration begins at 5:30 and the main event kicks off at 6:00.  Snacks and soft drinks will be provided.

I hope to see you there!

Driving Technical Change

A few nights ago I was over at my local Fry’s looking for a battery charger and a new Compact Flash card for my camera when I stumbled upon the book Driving Technical Change by Terrance Ryan.  I think it was the distinctive look of a Pragmatic Bookshelf title that caught my eye.  I picked it up, glanced over a few pages, said “what the hell,” and bought it.  The book weighs in a bit under 150 pages so it’s a pretty quick read.  Even with my slow reading pace and note taking I managed to make it through the book in just a few hours.

Is this good for the company?
– Office Space

Driving Technical Change is about learning how to “sell” new tools or techniques to your organization.  I really look at it as a marketing guide for developers.

The first step is to define what it is we’re trying to sell.  Is it a tool?  A technique?  Regardless, we need to recognize that we’re asking people to make some change to the way they work.  Once we’ve identified what we’re trying to sell we need to make sure that it is solving the right problem or if there even is a problem.  To do this we need to consider the skills available within the organization and consider alternative approaches.  Finally, we can start devising how we want to approach pushing this change into the organization and that is the focus of the book.

When I said that this book is a marketing guide for developers I wasn’t exaggerating.  Marketers define their audiences in terms of market segments.  Each segment is essentially a group people (or organizations) that share a common set of characteristics and/or behaviors which marketers use to tailor their message.  Driving Technical Change takes this approach by defining seven segments, err… skeptics:

1. The Uninformed
2. The Herd
3. The Cynic
4. The Burned
5. The Time Crunched
6. The Boss
7. The Irrational

Note: The author emphasizes that any given person can (and probably will) simultaneously classify as multiple skeptic types.

The skeptics are for one reason or another the pockets of resistance you will face when trying to get your organization to adopt your ideas.  It’s true that categorizing people in this manner can be dangerous but I don’t really think it’s harmful here.  The goal isn’t so much about categorizing people as it is their behaviors.

Just like market segments, addressing each skeptic requires a different approach.  Fortunately, the book also outlines several techniques for dealing with each type:

1. Gain Expertise
2. Deliver Your Message
3. Demonstrate Your Technique
4. Propose Compromise
5. Create Trust
6. Get Publicity
7. Focus on Synergy
8. Build a Bridge
9. Create Something Compelling

Most of these techniques apply to multiple skeptics and for each technique the book describes some tactics for effectively tailoring your message to the type.

I found the book interesting and recommend giving it a read.  I enjoyed the author’s style and found the anecdotes not only entertaining  but useful for illustrating each point.  Although much of the advice seems obvious in retrospect, having it organized in this manner can stimulate some thought.  Ultimately though, the underlying themes are to be knowledgeable, be prepared, be respectful, recognize that showing is almost always more effective than telling, and understand that there are some people that you can’t sway no matter what you do.

Note: For this article I used version 0.94 of the Moles Framework.

What is the Moles Framework?

Microsoft Moles is a project from Microsoft Research that came about because of work being done on Pex (another MS Research initiative). The Microsoft Moles Reference Manual describes Moles this way:

“The Microsoft Moles 2010 add-in for Microsoft Visual Studio 2010 is a lightweight framework for creating delegate-based test stubs and detours in .NET Framework applications.”

In other words, Moles is, in a sense, Microsoft’s answer to other mocking frameworks like Rhino Mocks or Moq but Moles differs from the other frameworks in a few ways.  One important distinction is that the Moles Framework does not provide any validation mechanisms of its own.  In that regard Moles is not so much a testing framework as it is an isolation framework intended for use in conjunction with other testing frameworks such as MSTest or NUnit.

Note: Although Moles started as part of Pex I’m not going to discuss Pex here.

Isolation Techniques

The Moles framework provides two isolation techniques:

• Stub Types
• Mole Types

Both types allow us to work around dependencies in different ways and have very different use cases.

Stub Types

Stub types are much like traditional stub or mock objects in that they allow us to test code that relies on some provided contract.  Stubs are based on inheritance so they can only be used with interfaces or non-sealed classes with virtual members.  Sometimes the code we want to test relies on static or non-overridable methods that can’t be stubbed.  In those scenarios we need to use mole types instead.

Mole Types

Mole types use a profiler to rewrite existing method bodies thereby allowing us to circumvent (or “detour” in Moles parlance) dependencies on static or non-overridable methods.  Mole types are generally most useful for isolating dependencies in third-party libraries.  Unfortunately, runtime rewriting does introduce some performance issues so moles should generally be used sparingly.

Note: At the time of this writing the Moles framework does not generate detour properties for auto-implemented properties although this could change in a future release (http://social.msdn.microsoft.com/Forums/en-IE/pex/thread/e5ce7b81-6b82-4e7c-bc99-2e7d81d9497d).

Choosing an Approach

With both stub types and mole types at our disposal it is important to understand when to use each.  In general Microsoft recommends that we favor stubs over moles whenever possible.  Stub types are much lighter than moles and operate over native language features.  Some instances where mole types are required are:

• Private methods
• Static methods
• Sealed types
• Static constructors/finalizers
• 3^rd party libraries without testable APIs

Getting Started

Installation

The Moles framework is available through the extension gallery as part of Pex (White box Unit Testing for .NET) or individually.  It can also be downloaded directly from the Microsoft Research site.  Regardless of which option you choose the functionality is made available to Visual Studio as an add-in.

Generating Stubs and Moles

As previously discussed, the Moles framework automatically generates the appropriate stub and mole types.  In order for it to generate the types though we need to first tell it which assemblies to inspect via a .moles file.

The quickest way to get started is to expand the References node in the test project, select the assembly being tested, and choose “Add Moles Assembly” from the context menu.  This will add a simple .moles file and automatically hook up the build action for the file.  When the project is built (or the .moles file is saved) Moles will generate an assembly with the appropriate isolation types and automatically reference it along with any other necessary assemblies.

Note: The Microsoft Moles Reference Manual describes adding the .moles file through the Add New Item dialog.  I couldn’t find these templates but did find the Add Moles Assembly context menu item on individual references. It’s also possible to manually add a .moles file and set the build action to Moles to achieve the same behavior.

Should it be necessary to generate isolation types for the types defined in mscorlib (i.e.: DateTime) we can add a moles assembly for it by right-clicking on the References folder in the test project and selecting the “Add Moles Assembly for mscorlib” option.

Basic Configuration

The .moles file is the heart of the Moles Framework configuration.  In its simplest form the .moles file merely identifies an assembly that will be inspected for type generation.

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
	<Assembly Name="Examples" />
</Moles>

In this example we’ve instructed the system to generate the isolation types for all types defined in the Examples assembly.

In addition to identifying the assembly the .moles file can also include additional configuration information for filtering which types will be stubbed and/or moled and strong name signing.  We’ll take a closer look at these topics later on in the Advanced Configuration section.

Naming Conventions

Once the types have been generated they can be referenced in your tests.  The Moles framework follows some basic naming conventions to make the types easier to find and identify in your code.  The full list of conventions is available in Appendix B of the Microsoft Moles Reference Manual so I’ll only note a few highlights here.

First, both of the isolation type implementations derive their names from their underlying types but use prefixes to distinguish them.  A prefix of “S” denotes a stub type whereas a prefix of “M” denotes a mole type.  For example, if you have a class named MyClass its corresponding stub will be named SMyClass and the mole type will be MMyClass.

Each of the isolation types are automatically placed in a .Moles sub-namespace under the namespace where the original types are located.  This means that if you have a User class in the Examples.Model namespace then the isolation types would be located in Examples.Model.Moles.

The exposed detour fields or properties on each isolation type also follow some basic naming conventions depending on what the underlying member is:

Delegation

One thing that stub and mole types have in common is that the framework generates both types for a given assembly.  By generating these types for us the framework saves us a great deal of time and allows us to focus on the problem at hand but if they are all generated how can we change their behavior?  The generator can’t possibly know how we intend to use them, can it?  Of course it can’t, but what it can do is expose fields that correspond to the various members and allow us to specify the alternate behavior with delegation.

Delegation is central to working with the Moles framework.  When the framework generates the stub and mole types it exposes the customizable pieces as properties.  One important thing to note about the delegate types Moles uses is that they’re not the standard Action<> or Func<> types that are provided by the .NET framework.  Instead, the Moles framework provides the static MolesDelegates class that exposes numerous generic types that represent functionality similar to the standard Action<> and Func<> types but expands upon them with additional overloads.  There are also some variations that accept some out or ref arguments as well.

Using Stub Types

As previously discussed, stub types should be used when we need to mock interfaces or virtual members of non-sealed classes.  Because stubs rely on inheritance they can be implicitly substituted for the stubbed type.

Methods

Methods can be stubbed by assigning a delegate with a matching signature to the corresponding field.  For example, if we have an interface:

public interface IMyInterface
{
	int DoSomething(int value1, int value2);
}

…and we want to stub the DoSomething method to return the sum of its two parameters we can easily set it up using a type initializer like so:

var stub = new SIMyInterface()
{
	DoSomethingInt32Int32 = (i1, i2) => i1 + i2
};

Generic methods are treated a bit differently than standard methods.  Rather than creating a delegate field for generic methods Moles generates an overload of the method that accepts a delegate matches that of the generic method.  To stub the generic method we pass a delegate for each type we want to stub to the overload and the stub class maintains an internal dictionary to track which generic instances are stubbed.

Properties

Because properties are really just syntactic sugar for accessor methods, stubbing properties is similar to stubbing methods.  Stub classes expose separate delegate fields for property getters and setters.  For instance, given a property on an interface:

public interface IMyInterface
{
	string MyProperty { get; set; }
}

…we can provide delegates for each accessor and simulate the property behavior in our test:

var value = default(string);

var stub = new SIMyInterface()
{
	MyPropertyGet = () => value,
	MyPropertySetString = v => value = v
};

Alternatively, Moles also generates a method to simplify this behavior:

var stub = new SIMyInterface();
stub.AttachBackingFieldToMyProperty();

Note: Each property with public get and set accessors will have a corresponding attach method.

Events

Stubs provide an easy way to test events by exposing a delegate field that can be invoked to raise the event.  This can be useful for ensuring that the correct handlers are hooked up correctly.  Stubbing an event is easiest when working with an interface since the event’s backing field will be exposed automatically but it’s also possible to stub an event on an existing class by making the event virtual.

To illustrate how an event is exposed through a stub consider the following:

public interface IMyInterface
{
	event EventHandler MyEvent;
}

When the Moles Framework builds the stub types it will include an EventHandler delegate field called MyEventEvent.

Partial Stubs

By default, when a stubbed member is invoked but doesn’t have an attached delegate a StubNotImplementedException is thrown.  This behavior makes sense when working with interfaces but what if we’re working with a class and want to use the base implementation rather than a stub?  The Moles framework lets us achieve this with partial stubs.  Activating partial stubs is simply a matter of setting the stub type’s CallBase property to true.

Note: The CallBase property is only generated for classes.

Behaviors

In the last section we saw that the default behavior for the Moles Framework is to throw a StubNotImplementedException when a stubbed member is invoked but doesn’t have an attached delegate.  This behavior is controlled through the aptly named IBehavior interface and can be set either globally or per stub type instance.

The Moles Framework includes a few built-in behaviors that are accessible through the static BehavedBehaviors class.  Of note are:

• BehavedBehaviors.NotImplemented - The default behavior, throws a StubNotImplementedException
• BehavedBehaviors.DefaultValue - Returns the default value: default(T), for the return type or does nothing for void

To set the behavior globally we just need to set the BehavedBehaviors.Current property:

BehavedBehaviors.Current = BehavedBehaviors.DefaultValue;

Alternatively, we can set the behavior for an instance by setting the instance’s InstanceBehavior property:

var stub = new SMyClass()
{
	InstanceBehavior = BehavedBehaviors.DefaultValue
};

We are by no means restricted to these behaviors either.  Should we need a custom behavior we just need to define a class that implements the IBehavior interface.

Using Mole Types

Although stub types are useful for interfaces and virtual members they can’t isolate everything and that’s where mole types come in.  As mentioned earlier, mole types allow us to detour virtually any .NET method.  The canonical example illustrating how handy mole types are involves a dependency most of us are all too familiar with: DateTime.Now.

Let’s assume we have some code to check if the end of the world is upon us:

public static class MayanApocalypse
{
	public static bool HasArrived()
	{
		return DateTime.Now >= DateTime.Parse("2012-12-21T00:00:00");
	}
}

Testing this code is a nightmare because DateTime.Now is non-deterministic due to its reliance on the system clock.  The fact that DateTime.Now is a static property doesn’t help matters any either.  Wouldn’t it be nice if we could force DateTime.Now to return some predetermined value?  Mole types let us do just that by injecting a callback into the MSIL body of DateTime.Now‘s get accessor and calling our custom implementation.

MDateTime.NowGet = () => DateTime.Parse("2012-12-21T00:00:00");

Assert.IsTrue(MayanApocalypse.HasArrived());

Accessing the Moled Type

Mole types derive from MoleBase<T>. This is an important distinction from stub types because it means that mole types don’t rely on inheritance. This has implications when we want to work with the moled type directly. Luckily MoleBase<T> provides a way to access the moled type through either the Instance property or an implicit conversion.

Instrumenting Mole Types

Due to how mole types work it’s necessary to run the tests under the Pex profiler.  MSTest handles this nicely through the HostTypeAttribute.  To instruct MSTest to run the tests under the Pex profiler simply decorate your tests:

[TestMethod]
[HostType("Moles")]
public void MyTest()
{
	// ...
}

It’s also possible to run moles under other test frameworks but additional setup work is required.  Refer to the Advanced Configuration section later in this guide for information about using Moles with NUnit.

One other consideration when using mole types is that it might be necessary to add an assembly attribute to allow some types to be instrumented, particularly for some classes in mscorlib.  For instance, moling the DateTime class requires us to add:

[assembly: MoledType(typeof(System.DateTime))] to our test project.

Methods

We already saw an example of moling a static method when we moled DateTime.NowGet. Moling instance methods is very similar but we have a bit more flexibility in that we can either provide delegates for individual instances or all instances of the moled type.

If we want to mole an instance method for all instances we hook it up through the nested AllInstances type. Each mole type has a nested AllInstances type that exposes write-only properties for setting the mole delegate.

Note: The Instance property is not available on abstract or static classes.

MMyClass.AllInstances.DoSomething = () => "Hello world";

Assert.AreEqual("Hello world", new MyClass().DoSomething());

Instance specific moles look much like their stub counterparts and we can set them in the same manner:

var mole1 = new MMyClass()
{
	DoSomething = () => "Hello world"
};

var mole2 = new MMyClass()
{
	DoSomething = () => "Goodbye"
};

Assert.AreEqual("Hello world", mole1.Instance.DoSomething());
Assert.AreEqual("Goodbye", ((MyClass)mole2).DoSomething());

Note: The Moles Framework will also provide properties for private methods provided that each type referenced in the method signature (parameter and return types) is accessible.

Events

Mole types handle events a bit differently than stubs.  Rather than exposing a field for the event Moles generates properties that represent the add and remove accessors.  For example, if you have the following event definition:

public event EventHandler MyEvent;

the mole type for the class will include properties named MyEventAddEventHandler and MyEventRemoveEventHandler.

Moling Members of Base Types

For this part of the discussion let’s assume a simple class hierarchy:

public abstract class MyClass
{
	public string DoSomething()
	{
		return String.Empty;
	}
}

public class MySubClass : MyClass
{
}

This structure poses an interesting problem for moles. The DoSomething method is defined on an abstract class and inherited by MySubClass but there is no DoSomething property generated for the MMySubClass mole so how can we mole DoSomething?

Note: The Moles reference manual recommends that this technique be reserved for constructor moles.

Each mole type actually has two constructors. While we primarily use the default constructor the other constructor lets us pass in another instance. In this case we can mole the DoSomething method by passing an instance of MMySubClass and passing it to the constructor for MMyClass:

var child = new MMySubClass();
var parent = new MMyClass(child)	// Note that child is implicitly converted here
{
	DoSomething = () => "Hello world"
};

Assert.AreEqual("Hello world", child.Instance.DoSomething());

Constructors

The Moles Framework also lets us mole constructors in a manner similar to how we mole static methods. Each constructor is exposed as a static write-only property named Constructor and following the naming conventions for parameter types as described above.

Note: There are no Constructor properties for static classes.

Static Constructors and Finalizers

Static constructors and finalizers can have some unexpected consequences when working with moles so there may be times that it’s necessary to work around them. Although we can’t mole them like we do with other members the Moles Framework provides a few attributes for simply erasing them.

To erase a static constructor use the following assembly attribute:

[assembly: MolesEraseStaticConstructor(typeof(MyClass))]

Similarly, to erase a finalizer use:

[assembly: MolesEraseFinalizer(typeof(MyClass))]

Note: Both of these attributes have overloads that allow specifying the assembly name and class name to identify the type.

Behaviors

Like their stub type counterparts, mole types also use behaviors to control what happens when a member hasn’t been moled. In many ways mole behaviors are just like stub behaviors in that they can be set either globally, per type, or per instance. The Moles Framework also provides several built-in behaviors for mole types. The default behavior even throws MoleNotImplementedException.

Despite their similarities though, mole and stub behaviors have very little in common. First, mole behaviors implement the IMoleBehavior interface. Additionally, the built-in behaviors and global behavior are all accessible through the static MoleBehaviors class.

Some of the notable built-in behaviors are:

• MoleBehaviors.NotImplemented – The default behavior, throws MoleNotImplementedException
• MoleBehaviors.DefaultValue - Returns the default value: default(T), for the return type or does nothing for void
• MoleBehaviors.Fallthrough – Calls into the original (unmoled) implementation

The MoleBehaviors class also exposes some methods to set the default behavior for a given type. For instance, if we want all mole types for MyClass to use the DefaultValue behavior we can use some code like the following:

MoleBehaviors.BehaveAsDefaultValue(typeof(MyClass));

var mc = new MMyClass();
// Unmoled method returns "Hello world"
Assert.AreEqual(null, mc.Instance.DoSomething());

Advanced Configuration

So far we’ve covered the basics of using the Microsoft Moles Framework and largely stayed with the default configuration. Moles configuration provides options to restrict which isolation types are generated, provide a strong name, and control the target platform for the moles assemblies.

Note: The reference manual states that it is possible to disable compilation and add the generated code to the project but I haven’t been able to get that feature to work. If anyone has any insight on this I’d love to see an example of it working.

Controlling Type Generation

Generating the isolation types can be an expensive operation that greatly extends the amount of time needed to build the solution. You can control what is generated in the .moles file by including the StubGeneration and/or MoleGeneration elements within the Moles element. As their names imply, these elements control what will be generated for stubs and moles respectively.

The most basic way to restrict what is generated is to simply set the Disabled attribute to true on either element to prevent the framework from generating anything of that type.

<Moles xmlns="http://schemas.microsoft.com/moles/2010/" Diagnostic="true" DisableCache="true">
	<MoleGeneration Disable="true" />
</Moles>

Controlling isolation type generation doesn’t have to be an all-or-nothing approach though. Both elements also support a nested Types element that allows for more precise filtering based on a simple syntax. The Types element is constructed with the familiar combination of Clear, Add, and Remove elements that are frequently used in standard configuration files.

The Add and Remove elements define a number of common attributes that help refine which types will be included or excluded from the code generation.

^* – Only valid on Remove elements

The value of each of the string typed attribute above are actually filter pattern definitions. By default the patterns are used for case-insensitive partial matching but we can control that behavior with a few tokens.

• Appending ! to the end of the pattern forces an exact, case-sensitive match
• Appending * to the end of the pattern will match the beginning of the string

Multiple patterns can be combined using a semi-colon delimited list.

<AssemblyName="mscorlib"/>
	<StubGeneration>
		<Types>
			<Clear />
			<Add Namespace="System!" />
			<Add Namespace="System.IO!"/>
			<Remove TypeName="Handle" />
		<Types>
	</StubGeneration>
</Assembly>

Using the example above (taken from the reference manual), Moles would only generate stub types for the types in the System and System.IO namespaces and excludes anything containing “Handle” in the name.

Strong Name Signing

By default, the generated assembly will be signed with the same key as the moled assembly if it is strongly named. If it’s necessary to use a different key we just need to specify the path to the key file in the Compilation element’s KeyFile attribute in the .moles file.

<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
	<!-- ... -->
	<Compilation KeyFile="key file path" >
</Moles>

Setting the Target Platform

Should it be necessary to force the moles profiler to run as a 32 or 64-bit process we can do so with the MolesAssemblySettingsAttribute found in the Microsoft.Moles.Framework namespace. We just need to include the attribute as an assembly attribute and set Bitness parameter accordingly. For instance, to use a 64-bit process we could use:

[assembly: MolesAssemblySettings(Bitness = MolesBitness.x64)]

Other valid options for Bitness are MolesBitness.x86 and MolesBitness.AnyCPU.

Using with NUnit

Being a project from Microsoft Research it’s no surprise that Moles is easiest to use with MSTest. As we discussed, to get Moles to work with MSTest we just need to decorate the test methods with [HostType("Moles")] and MSTest will set up the instrumentation accordingly.

Of course, not everyone is using MSTest so we need a way to run moled tests with other frameworks. The good news is that yes, Moles can be used with other frameworks. The bad news though is that it takes some extra effort to make it work. Although I’m focusing on using Moles with NUnit the process is similar for other frameworks like xUnit or MbUnit.

NUnit requires the Microsoft.Moles.NUnit assembly to be registered as an add-in. The Moles Framework ships with a copy of this assembly but it is built against a specific version of NUnit (2.5.2.922 in my case) so if you’re using a different version of NUnit (I’m on 2.5.10.11092) you’ll need to recompile the assembly with the correct NUnit assemblies. Once you have a version of the add-in assembly that corresponds to your NUnit version you can copy into the bin\addins folder to register it with NUnit.

Note: The source for the add-in assembly is available in the moles.samples.zip file located in the Documentation folder under the Moles installation folder.

The add-in assembly defines the MoledAttribute class that sets up the mole context in the NUnit runner. You’ll need to reference the assembly in your test project and import the Microsoft.Moles.Framework.NUnit namespace. For convenience I referenced the version of the DLL that I’d placed in my add-ins folder.

You might think that since you’ve registered the add-in and built the projects that you’re ready to run the tests. In a sense, you are but there are a few nuances to be aware of first.

1. The GUI test runner doesn’t work with Moles
2. The tests need to be run under the context of the Moles test runner

To run the tests with NUnit’s console runner under the context of the Moles runner you can use the following command:

moles.runner.exe /r:nunit-console.exe /args="/domain=None" [test assembly name]

Wrapping Up

So that’s Microsoft Moles in a nutshell. If you like what you see I encourage you to download it and give it a try. Of course, if you found any errors in what I’ve shown or think I missed something important please let me know in the comments.

Some say companies and recruiting firms are using tests based on incorrect assumptions on how developers do their work. C# and jQuery and JavaScript and VB and the .NET framework continue to offer new capabilities. The complexity has generally not been a problem for you because you make liberal use of IntelliSense, online help, books online, reference books, Google searches, and technical online forums. You know how to quickly find information when you can’t remember specific syntax. So, can you pass that technical screening test? Should you need to be tested? Let’s find out

Don’t forget about the C# and JavaScript SIGs after the main event either.  I’m not sure what the JavaScript group is covering but for the C# group Alex Gheith and I will be leading a discussion over a few of the items in chapter 1 of Effective C# by Bill Wagner.

As always registration begins at 5:30 with the main event starting at 6:00.  Thanks to our sponsors food and drink will be provided before the meeting.

Please be aware that our meeting location has changed.  For January and February we’ll be meeting in the 2^nd floor conference room in Parkwood 9.  For those that remember when we had meetings in the 5^th floor conference room in the same building rest assured, the 2^nd floor conference room is better suited to our needs.

I hope to see you there!

Box selections let us quickly make the same change to multiple lines simultaneously.  Creating them is easy – just hold shift+alt and use the arrow keys or hold the alt key while left drag the mouse to define a rectangle.  If you just want to insert the same text onto multiple lines you can define a zero-length box by expanding the box vertically in either direction.

So what makes box selections so useful?  Some of the things I find them most useful for are changing modifiers and making local variables implicitly typed.  To illustrate, let’s take a look at a few non-virtual properties that we’d like to make virtual.

Making these properties virtual without a box selection certainly isn’t difficult but it’s definitely tedious.  A box selection lets us make them all virtual at the same time so we can get on with the task at hand.  The thin blue line immediately following the public modifier on each property identifies the zero-length box that serves as the point where we’ll insert in the virtual modifier.

To insert the virtual modifier we just need to type (or paste) “virtual.”  Here you can see that each property is now virtual and the zero-length box has moved to the end of the inserted text.  What if we decide later though that these properties shouldn’t be virtual after all?

We can use box selections to remove the virtual modifier from each property just as easily.  In the example to the left we see a box selection highlighting the virtual modifier on each line.  To remove the text we can simply delete it.  This will leave us with a zero-length box where the virtual modifiers used to be.  We can then simply click or arrow away to clear the box selection.

Box selections can go a long way toward increasing your productivity by reducing some of the more tedious aspects of programming.  The few seconds they save here and there can really add up over the course of a day.  More importantly though, that time can be spent on the real problems we’re trying to solve.

Further Reading

How to: Select and Change Text

The best-laid plans of mice and men often go awry

When I named this site Two years ago I was really serious about both software development and photography and fully intended to use this space to explore both subjects.  Over time though I began thinking that I should focus on one or the other.  Given that programming is my chosen profession it was only natural that I take the site that direction.  For that reason that I decided to retire “The Programmer’s Lens” as the name of the site.  I think the new name, Didactic Code, more accurately reflects the purpose of the blog.

Didactic: intended to convey instruction and information as well as pleasure and entertainment
– Merriam-Webster Dictionary

This space is a learning tool.  I’m not ashamed to admit that I write for myself just as much as I do for others.  Writing about these topics is the most effective way for me learn about them.  I also like to share what I’ve learned so when others find benefit in my writings that’s just icing on the cake.

I’ve left the handful of photography related posts intact (not that they get any traffic) but I’ll no longer consider photography as part of this blog.  Should you be interested in my photos feel free to peruse my Flickr photostream.

So what do you think of the change?  Do you like the new name or should I change it back?

Here’s an excerpt from the report:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

2011 was a good year for me and my family.  We wish everyone the best for the new year.