We just released Pex and Moles v0.94 which brings MSBuild support for Moles! 

Moles is now entirely based on MSBuild and does not require to check in any generated files. All the previous headaches related to locked files in TFS are now a history. Moles assemblies will be generated on demand during the build. We strongly recommend you read the upgrade instructions in the release to see how you can smoothly upgrade to v0.94.

And while the installer is running, don’t forget to solve a duel or two at http://www.pexforfun.com …

Cheers, the Pex Team.

We’ve just released a new version of Pex and Moles v0.92. This version brings Rex integration (smarter about regular expressions), Silverlight support (Alpha) and a number of bugs/improvements here and there.

Read all about the new stuff on the release notes page. Happy Pexing!

This post shows how you can leverage the un-typed Detours API to extend any mock framework to support static methods, sealed types, etc…

Moles is an isolation framework for .NET that the Pex team designed to make Pex happy. It relies heavily on delegates and comes with a syntax of its own. Moles is actually a simple strongly typed layer on top of a un-typed general purpose detour API. If you do not like the Moles syntax, you can still leverage the detours API to deal with static methods or sealed types.

Let us see how we can use the detour API to build a micro-mock-framework using expressions trees. Let’s call it Deq.

The Challenge

As usual, we’ll toy with an example where we need a very particular DateTime.Now value. Since DateTime.Now is a struct living in mscorlib.dll, it cannot be mocked using traditional approaches –DateTime.Now can’t be overloaded. The test case looks like this and will most likely fail.

The Whish

We would like to be able to replace the implementation of DateTime.Now with a method that always returns the year 2000 in the context of the test. If possible, we would like to use a strongly typed, Linq-ish, expression tree based syntax to do this. For example, we could think that a Deq class would define a Replace(Expression<Func<T>> method, Func<T> detour) method that would achieve this detour:

 Implementing Deq on top of MoleRuntime

The implementation of Deq.Replace relies on MoleRuntime.SetMole, an un-typed API to replace methods that Moles builds upon. First, one needs to walk the expression tree to extract the MethodInfo that the user wanted to replace (I’m not showing this code here, it is beyond the point of this blog post). Once you have the method, you can use the Moles API to install the detour. This happens through the MoleRuntime.SetMole method and the rest is taken care of the Moles runtime.

That’s it. You’ve just written a micro-mock framework that can isolate from static methods.

To get this code to compile, you will need a reference to Microsoft.ExtendedReflection.dll and Microsoft.Moles.Framework.dll. Also, since the Replace method only works for the Func<T> method, you’ll probably want to write a T4 template that takes care of all the other delegates (Func<T,T2>, Action<…> etc…).

Deq Sources?

The Deq sources are available in the Samples solution that ships with Pex.

Although Pex is only available for MSDN subscribers, Moles can be freely downloaded as a standalone tool on Visual Studio Gallery.

http://visualstudiogallery.msdn.microsoft.com/en-us/b3b41648-1c21-471f-a2b0-f76d8fb932ee

(off course, both tools are also available under an academic license too)

We just uploaded a new release 0.91 on MSDN, Visual Studio gallery and our research web site. Learn more about the changes at http://research.microsoft.com/en-us/projects/pex/releasenotes.aspx#0_91

Get and download Pex!

La presentation sur Pex et Moles pour SharePoint que j’avais presente a Paris est online…

We just released an update of Pex on Devlabs that adds support for Visual Studio 2010 RC (the release also contains a number of bug fixes). Read more about it on our release notes page.

We just released a new version of Pex and Moles that brings a number of bug fixes and various improvements to the behaviors for SharePoint and Asp.NET.

Improvements

• Interaction with the Source Control provider has been significantly improved for Moles
• Support for Moles of nested types.
• Improved logging in the Host Type
• Improved Behaved collections
• Added Behaved types for mscorlib and System.Web types.

Bug fixes

• Updated several outdated section in the documentation
• Updated missing classes in the SharePoint samples
• Fixed a limitation of the profiler that would silently fail to instrument certain methods

Breaking Changes

• We have formalized the naming convention of Moles and Stubs and found some holes along the way. Some mole method might have a new name under this version of the compiler.

We just released Pex 0.21.50115.2. This release brings bug fixes, a big renaming from “Stubs” to “Moles” and improved infrastructure to build behaved types (formerly known as beavers).

Bug Fixes

• The Moles VsHost fails to execute unit tests in different assemblies.
• Pex deletes the report folder it is currently writing to.
• Support for named indexers in Stubs
• Fixed bugs in how Pex reasons about System.Convert.ToBase64, DateTime
• Invalid support for protected members in the stubs generation

Breaking changes

• The Stubs framework was renamed to Moles framework. We have decided to make the Moles the center of the framework and as a consequence, renamed ‘Stubs’ to ‘Moles’. (This does not mean that we encourage writing untestable code, as Mole help to make it testable. You should still refactor your code to make it testable whenever possible, and only use Moles when that’s the only choice). The impact is that
  • Microsoft.Stubs.Framework was renamed to Microsoft.Moles.Framework
  • The moles and stubs get generated in subnamespaces ‘.Moles’ rather ‘.Stubs’.
  • See below for the list of steps to upgrade your applications.
• BaseMembers in Moles have been deprecated: this helper is not useful as it can be acheive in a better way through a constructor. We decided to remove it to reduce code size. The second reason is that BaseMembers would only work for types inside of the same assembly, which might seem inconsistent.
• PexGoal.Reached is replaced by PexAssert.ReachEventually(). The PexGoal class has been integrated into PexAssert through the ReachEventually method which should be used with the [PexAssertReachEventually] attribute.
• PexChoose simplified: we’ve simplified the PexChoose API; you can now get auxiliary test inputs with a single method call: PexChoose.Value<T>(“foo”).

Migrating from previous version of Pex

Since we’ve renamed Stubs to Moles, any existing .stubx files will not work anymore.

Take a deep breath, and apply the following steps to adapt your projects:

• change the project reference from Microsoft.Stubs.Framework.dll to Microsoft.Moles.Framework.dll
• rename all .stubx files to .moles, and
  • rename the top <Stubs xml element to <Moles.
  • Change the XSD namespace to http://schemas.microsoft.com/moles/2010/
  • Right click on the .moles file in the Solution Explorer and change the Custom Tool Name to ‘MolesGenerator’.
  • Delete all the nested files under the .moles files
• Remove references to any compiled .Stubs.dll files in your project
• In general, remove all .Stubs.dll, .Stubs.xml files from your projects.
• Rename .Stubs namespace suffixes to .Moles.
• replace all [HostType(“Pex”)] attribute with [HostType(“Moles”)]
• in PexAssemblyInfo.cs,
  • rename using Microsoft.Pex.Framework.Stubs to Microsoft.Pex.Framework.Moles
  • rename [assembly: PexChooseAsStubFallbackBehavior] to [assembly: PexChooseAsBehavedCurrentBehavior]
  • rename [assembly: PexChooseAsStubFallbackBehavior] to [assembly: PexChooseAsMoleCurrentBehavior]
• In general, the ‘Fallback’ prefix has been dropped in the following methods:
  • rename FallbackAsNotImplemented() to BehaveAsNotImplemented()
  • rename class MoleFallbackBehavior to MoleBehaviors
  • rename class StubFallbackBehavior to BehavedBehavors

We just released the version 0.20 of Pex. This version brings a Beavers, an extension of Stubs to write models, a global event view in Visual Studio and many bug fixes. Beavers are a small programatic models that build upon Moles…

• Beavers: With stubs and moles, we provided a framework to write record/replay tests (i.e. mock-based tests) against any .NET type, interface or not. Beavers take you to the next level and allow you to write simple implementations with behavior (hence the ‘B’eaver) that can be used to replace the external system during testing. The benefit of using Beavers is that the resulting test cases are much more robust to code changes since the tests specify the state of the system, rather than a sequence of method calls and outcomes. We will talk a lot about Beavers in the future. Let’s take a look at an example. The following snippet uses Moles to redirect the constructor of a Bank class, then sets up the GetAccountById(int) method to return an instance of IAccount, etc… This is a typical test that is based record and replay. The problem with this technique is that it is really fragile with respect to code changes: if the code calls different methods, the test will break.
  
  The same behavior can be specified using Beavers. Beaver are simple implementations that simulate that capture enough behavior of the original code for testing. Using Beavers, one can specify the state of the system. The functional behavior is re-factored away in a Beaver class and reused in all tests!
  
• Global Event View: when executing multiple explorations, it was cumbersome to go through each exploration to investigate the events (instrumentation, object creation, etc…). We have added a view in the Pex Explorer tree view that centralizes the events for the entire run.
  
• Beavers for SharePoint: The samples that come with Pex contains a number of Beavers for the SharePoint object model (SPList, SPListItem, SPField, etc…) that should help you get started with testing SharePoint with Beavers. As an example, you can compare a mole-based test (left) and a beaver-based test (right) for a simple SharePoint service:
  
• Bug fixes and Improvements:
  • The HostType crashes non-deterministically.
  • Visual Studio 2010 crashes when loading with a ‘DocumentSite already has a site’ error message.
  • The Stubs code generator uses a lot of memory and may crash Visual Studio. The Stubs generator now runs out of process and does not take down Visual Studio when it runs out of memory.
  • The Stubs code generator detects version changes of the Stubs framework to regenerate the stubs assemblies.
  • The Pex execution produces less warnings. We’ve reviewed our warnings and moved some, who did not matter, as messages.
  • When a Contract.Requires is failed multiple time in a stacktrace, do not allow it.
  • The object factory guesser has partial support for internal types and internal visible to (signed assemblies not supported).
  • The ‘add’ and ‘remove’ of events can be moled to deal with events.
  • Digger does not work in Visual Studio 2010 when no test project exists.
• Breaking Changes: The Beavers introduced a number of refactoring that might impact users of Stubs and Moles. The .stubx file should regenerate themselves automatically, otherwise right click on the file and select ‘Run Custom Tool’.
  • Most types of the Stubs framework have been moved to sub namespaces.
  • IStubBehavior was renamed to IBehavior
  • StubFallbackBehavior was renamed to BehaviorFallbackBehavior
  • PexChooseAsStubFallbackBehaviorAttribute was renamed to PexChooseAsBehavedFallbackBehaviorAttribute
  • PexChooseStubBehavior was renamed to PexChooseBehavedBehavior
  • PexExpectedGoalsAttribute and PexGoal.Reached(…) were renamed and refactored into PexAssertReachEventuallyAttribute and PexAssert.ReachEventually(…);

J’aurai le plaisir de presenter ‘Stubs, Moles and Pex’ au premier rendez-vous de DotNetHub 20 janvier 2010 a LLN. DotNetHub est une communaute .NET francophone recemment cree. Au programme, beaucoup de demo a propos de Pex, Stubs et Moles, et aussi d’un nouvel animal – les Beavers.

Ce sera ma premiere presentation 100% en francais, ce qui en soit est un challenge assez interressant!

ps: Pas d’accent sur les claviers qwerty, ce qui rend l’ecriture du francais beaucoup plus facile :)

I’ll be presenting the latest development on using Moles and Pex to unit test SharePoint 2010 (or 2007) Services at the SharePoint Connnections in Amsterdam, 18th-19th of January.

MSC26: Pex - Unit Testing of SharePoint Services that Rocks!
SharePoint Services are challenging for unit testing because it is not possible execute the SharePoint Service without being connected to a live SharePoint site. For that reason, most of the unit tests written for SharePoint are actually integration tests as they need a live system to run. In this session, we show how to use Pex, an automated test generation tool for .NET, to test SharePoint Services in isolation. From a parameterized unit test, Pex generates a suite of closed unit tests with high code coverage. Pex also contains a stubbing framework, Moles, that allows to detour any .NET method to user-defined delegates, e.g. replace any call to the SharePoint Object Model by a user-defined delegate.

We just released the Pex 0.19.41110.1 just in time for TechEd session. This version brings an updatedsupport for Visual Studio 2010 Beta2 and .NET 4.0 and many improvements to the Moles.

• Better Dev10 Beta 2 support! We’ve upgraded our support for Visual Studio 2010 Beta 2. This includes full support for .NET 4.0 Beta 2, the Visual Studio Unit Test HostType and the Visual Studio integration.
  Known Beta 2 issues: 1) When running Pex for the first time, the path to Visual Studio Unit Test is not found. You need to specify the Visual Studio ‘PublicAssemblies’ path (“c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies”), 2) Don’t run Pex on v2 projects, Pex will crash.
• Smooth generation of Stubs and Moles: when you create a stubs and moles assembly that is not a project reference, like one of the system assemblies, the stubs and moles code generator will automatically compile it into an assembly and add it to the project. This dramatically increases the performance of projects using Stubs and Moles.
  
• Stubs and Moles for VisualBasic.NET: the Stubs and Moles may be used in VisualBasic.NET projects. In that case, they are embedded as a compiled assembly.
• Moles support for NUnit, xUnit.Net and others: Unit tests involving Moles require the Pex profiler to work. We’ve added a new mode to our command line runner that allows to execute your favorite unit test framework runner under Pex. For example, the command “pex /runner=xunit.console.exe tests.dll” will launch the xunit runner for test.dll under Pex. x64 assemblies are still not supported.
  
• Nicer Moles Syntax: we’ve added some little tweaks to the Moles API, such as an implicit conversion operator to the moled type, that simplifies the syntax. Here is a small example that showcases the current syntax: step 1 moles the Bank constructor, step 2 moles the GetAccount method and returns a mole of Account, step 3 moles the getter and setter of the Balance property.
   
• Fluent Mole Binding: The Bind method returns the mole itself which allows it to be used in a fluent fashion. Interface binding is specially useful when you need to mole custom collections – just attach an array! For example, we attach an array of integers to a the MyList type that implements IEnumerable<int>.
   
• Breaking Changes in Stubs and Moles:
  • The stubs and moles code generator tool is now ‘StubsGenerator’. You need to path this value in the property pages of your .stubx pages.
  • No more AsStub and AsMole: the AsStub and AsMole helpers were confusing and pretty useless so we decided to reduce the amount of generated code by removing them.
  • The naming convention for Stubs delegate fields always mangles the parameter types of the stubbed method, i.e. Foo(int) yields to a field called FooInt32. We used to be smart about adding parameters but we decided to make the scheme stable and symmetric with respect to the Moles.
  • The ‘FallbackBehavior’ property has been renamed to ‘InstanceFallbackBehavior’ in both Stubs and Moles to make it more explicit.

As usual, we’ve also fixed a number of bugs and added features that were reported through our MSDN forums.

I’ll be presenting Stubs and Moles at the Visual Studio User Group on November 3rd. See you there…

Stubs is a lightweight framework for test stubs and detours in .NET that is entirely based on delegates, type safe, Refactorable, debuggable and source code generated.
Stubs also allows to replace  any .NET method with a user-defined delegate, including non-virtual/static methods in sealed types. Stubs is fully integrated into Pex , an automated white box test generation tool for .NET.
http://research.microsoft.com/en-us/projects/stubs/