24 October 2011

What are .MOLES Files?

After clicking the Add Moles Assembly option, in the Solution Explorer context menu, a file with extension .moles is added to the test project.  This file contains an instruction for the compiler, that requests a mole assembly to be generated for the specified assembly.  Without these files, no moles assemblies will be generated.

Moles Error Says I Haven't Instrumented a Type. What Does That Mean?

There are three possible causes for instrumentation exceptions:

Using Declarations and Assembly Attributes
You must ensure a MoledType assembly attribute is present, for the type specified by the exception.  For example:

[assemblyMoledType(typeof(System.IO.File))]

Refer to the How Do I Make My Test Use Moles post, for more details.


Mode of Execution
If you are certain you have included all of the required using declarations and assembly attributes, examine your method of execution.  Pex and Moles tests require special instructions to be sent to the compiler, to properly route calls through the Moles assembly.  Third party test execution utilities, such as CodeRush, do not provide this supplemental information.  A missing instrumentation exception will be thrown, when Pex and Moles tests are executed by CodeRush.


Unsupported Test Framework
Pex and Moles support both the Visual Studio and NUnit Test Frameworks.  Other frameworks are not supported.

Why Doesn't the .Moles Assembly Appear in Solution Explorer?

There are two common answers to this question:
  1. Compile the test project.  The moles assemblies are generated on compile.
  2. Select the project in the Solution Explorer window, and then click the Show All Files button.  A hidden folder named MolesAssemblies will appear.
There should be no reason to handle the moles assemblies, since they may be frequently regenerated.

Where Are the Moles Assemblies?

"I compiled my test project, after asking to mole an assembly.  I see the .moles file, but where is the moles assembly?"

Moles assemblies are visible in the Solution Explorer window, by clicking the Show All Files button.  (Be sure the proper project is selected, first!) All moles assemblies are found in the hidden MolesAssemblies folder.

How Do I Make My Build and/or Test Servers Use Pex and Moles?

All build and test servers (e.g. MSBuild) that must handle Pex and/or Moles have the Pex and Moles Framework installed.  After installation, the builds and tests should execute normally.

22 October 2011

How do I make my test use Moles?

NOTE: The Moles isolation framework must be installed to any machine that will compile the solution and/or execute the mole tests.

The following things must be done, to use Moles in a test.  This looks like a lot, now.  However, you'll quickly get the hang of things, and have these steps done in seconds!  Using my CodeRush Moles templates will help speed things up.

21 October 2011

How Do I Mole .NET Framework Types?

Moles ships with pre-compiled moles assemblies for the entire .NET Framework (mscorlib).  (This used to be a huge pain to compile!)  Adding the moled mscorlib is easy.  Just follow these three steps:

11 October 2011

How do I Mole an Assembly?

Creating a Moles wrapper assembly ("moled" assembly) has been greatly simplified:
  1. Expand the test project node, in the Solution Explorer window
  2. Expand the References child node
  3. Right-click the assembly you wish to mole -- the context menu appears
  4. In the context menu, select the Add Moles Assembly option -- a .moles file appears in the text project
  5. Build the test project

10 October 2011

What is Pex and Moles?

UPDATE
Please be aware the Moles Framework has been productized and released as Microsoft Fakes Framework, in the Visual Studio 2012 Ultimate and Premium (with Update 2) SKUs. Pex seems to have evaporated -- I hear no news regarding Pex, from the internals of Microsoft. This information is intended for historical reference for developers that still use or encounter these technologies.


This is the first post in a series. Please visit the new Testing wih Pex and Moles page, for an index to all related posts.

Microsoft Pex and Moles are a set of automated white box unit testing utilities, developed by Microsoft Research in Software (RiSE) group.  As of writing this post, the Pex and Moles package is version 0.94.51023.0, and has been in development for several years.  The first public release of Pex was released in mid 2008.  Moles debuted as a host type, in late 2009.  These both matured greatly, until October 2010.  Since that time, no subsequent releases have been issued.  This could mean the technologies are being polished up for release, or waiting for an opportunity for release with another project like Visual Studio 11.  There are still some seemingly obvious features that are missing, so the case could also be that it is simply put on the back burner for a while.  However, the late addition of MSBuild support suggests otherwise.


UPDATE (21 OCT 2011):
I suspected that something was going on with Pex and Moles, since the releases are running out of beta numbers (0.92.xxx), and nothing new has been released for a year.  This typically indicates the project has been handed off to another team for integration in to a release product.

I asked a very respectable member of the Microsoft Visual Studio development team, if Pex/Moles or some other dependency isolation mechanism will be introduced in Visual Studio 11. In traditional Microsoft "I will nether confirm nor deny" fashion, this individual told me, "Dependency isolation will be taken care of, in Visual Studio 11."  It appears Pex and Moles are finally being rolled into Visual Studio!  The current VS11 preview does not yet include dependency isolation features.  Hopefully, this information I have blogged will become obsolete!

Note, this VS11 download is a PREVIEW, not a BETA, or even an ALPHA.  Many more features are still cooking.  Stability is OK, but use it at your own risk!


06 October 2011

The Toolbar and Blank Key Challenges

I issue two challenges, in this post.  The first gives you geek points; the second geek cred; and both together, a substantial step forward in becoming an ubergeek.

1. Turn off all toolbars in your Visual Studio.
I've never used them (admittedly, I do have the Solution Configurations" and Stop Debugging commands in the menu bar), and didn't realize how often many developers use them.  I was working a Kata session at Utah Code Camp and SQL Saturday 94, this last weekend, with a fellow who used Cut and Paste commands in the context menu.  That may be a step or two beyond "crutch" status.  Incidentally, Scott Hanselman posted something similar to his blog, earlier this year.

Note, we both disabled the navigation bar at the top of documents (Tools > Options > Text Editor > All Languages > General > Navigation bar).

2. Get (and use) a keyboard with no key labels.
At the aforementioned  Utah Code Camp, David Adist showed up in the speaker green room with a blank keyboard.  Although I had seen them before, I never though I could use one.  He claims that experienced programmers already have a good sense of touch-type; but, you can't exercise your ability when you can cheat by looking at the keys.

Das Keyboard has two models: silent and mechanical.  The mechanical version gives you that great, "clacky" sound that makes you sound like you're typing very fast (even though half of those keystrokes are the backspace key!).