Microsoft Enterprise Mocking Block

time to read 21 min | 4031 words

It has come to my attention that Microsoft will be soon releasing a CTP of a new block in the EntLib series. Following to footsteps of the Policy Injection Block, the Enterprise Mocking Block will allow developers to finally cease to write expectations for mock objects with 70% less code than before.

Based of proven practices from the field, the Microsoft Enterprise Mocking Block is capable of producing a fake implementation of an interface, with hardly any code at all. I am afraid that words would fail to describe what the guys at Redmond have done, so I have better show you what it can do.  Here is a simple example of the power:



public void MicrosoftEnterpriseMockingBlockApril1st()


       FakeObjectsFactory fakeObjectFactory =




       FakeObjectCreator emailSender_Send = fakeObjectFactory.FakeObjectCreator("EmailSender", "Send");

       IEmailSender FAKE_EmailSender = fakeObjectCreator.ToFakeObject<IEmailSender>();


       ClassUnderTest cut = new ClassUnderTest(FAKE_EmailSender);


       cut.SendEmail("blah", "bar");


       FakeObjectConsilidator consilidator = fakeObjectFactory.CreateFakeObjectConsilidator("EmailSender");


       FakeObjectTestVerifier  verifier =



Some of you noticed the referenecs to various XML files in the tests. Indeed, breaking from the worst practice behavior of placing tests decisions in code, the Microsoft Enterprise Blocking Mock not only enable, but requires that you would be flexible, and specify your intent in an easy to ready, easy to modify set of XML files.

Here is an example of sendEmail_Failure.expectation.def.xml:

<interactionBasedText microsoftEnterpriseMockingBlock:typeToIntercept="App.Interfaces.IEmailSender">


              <expectation for="Send">


                           <parameter value="" />

                           <parameter value="message title" />

                           <parameter value="message content" />


                     <expectationOptions repeatMin="1" repeatMax="1"/>


                           <exception type="System.Net.NetException">

                                  Unable to connect to SMTP Server







There are couple of caveats to this approach. Since mocking is such an invasive procedure, with potentially dangerous implications, you would need to OptIn by marking the interfaces with special attributes, thus allowing the Microsoft Enterprise Mocking Block to fake them. Here is how such an interface may look:


public interface IEmailSender



       void SendEmail([MockableParameter] string to, string body);


While Microsoft Enterprise Mocking Block is currently not able to mock classes (or interfaces not mark specifically so), there are some distant voices saying that it should support those options. Microsoft is carefully considerring the customer feedback, and the team will evaluate the options to implement these advanced, rarely used or needed, features in a future version.

Naturally, I am excited to see a true Enterprise Mocking Framework arrive on the scene. A little bird has whispered that there may also be a designer in the works, but it is expected to ship only in the post Orcas' timeframe.