Microsoft Enterprise Mocking Block
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:
[TestMethod]
[InterfactionBasedTestMethod(FakeObjectOptions.AllowCreateFakeObjects)]
public void MicrosoftEnterpriseMockingBlockApril1st()
{
FakeObjectsFactory fakeObjectFactory =
Microsoft.EnterpriseLibrary.Mocking.Framework.FakeObjectsFactory.Create();
fakeObjectFactory.Initialize("emailSender.mock.def.xml",
"sendEmail_Success.expectation.def.xml",
"sendMail_Failure.expectation.def.xml");
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");
consilidator.TryStopTest(FAKE_EmailSender);
FakeObjectTestVerifier verifier =
fakeObjectFactory.CreateFakeObjectTestVerifier("sendEmail_Failure.expectation.verification.xml");
verifier.Verify(FAKE_EmailSender);
}
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">
<expectations>
<expectation for="Send">
<parameters>
<parameter value="foo@bar.com" />
<parameter value="message title" />
<parameter value="message content" />
</parameters>
<expectationOptions repeatMin="1" repeatMax="1"/>
<methodResult>
<exception type="System.Net.NetException">
Unable to connect to SMTP Server
</exception>
</methodResult>
</expectation>
</expectations>
</interactionBasedText>
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:
[Mockable(MockableOptions.I_ReallyDoMeanIt)]
public interface IEmailSender
{
[MockableOperation(MockableOperationOptions.OnlyWhenTheMoonIsFull)]
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.
Comments
April Fool's Day to you too : - D
You know, that's exactly how they'd do it too. I'm almost horrified to see how much design time goop their new MVC web framework will end up with.
Sorry, dude, you failed to capture the verbosity that MS puts on their EE XMLs. And btw, that's a good thing. :-)
As usual, Microsoft are just copying ideas taken from the Java world. See this announcement
April fools or a replacement for Rhino? I say a well written blog entry. I'll stick with Rhino thanks.
Yikes! Like Hammett said, you know there's actually going to be more XML when they produce it. ;-)
Boy, I laughed so much I nearly lost my breath. Nice one!
Nice one bro. It was a bit obvious from the get-go though :) And Jeremy is right, that's probably pretty nail-on-the-head to how MSFT will do it someday.
:-)
Hi,
Good !
MicrosoftEnterpriseMockingBlockApril1st() was a bit obvious.
Thanks.
The designer, codename RhinoHunter, may be officially released as Windows Mock Designer. Of course, as testing and mocking are enterprise things (not things average developers require) you'll need VSTS edition Mockup edition (ERP $8,000). This will include the prerequisites, Guidance Automation toolkit & the guidance automation extensions, thus allowing the rapid creation of Mock Recipes inside the IDE.
Ha ha ha. Excellent work Ayende. I think what makes this April Fool's joke so good is its believability.
Guffaw!
Haha. Very Nice. I was just about to turn around to the developer next to me and start ranting about microsoft's most recent fubar when it dawned on me. Well done.
@Hammett,
That was on purpose, I really didn't have three hours to write XML just for an april's fool joke.
That was hilarious! I bet there's a few bright sparks at Microsoft wondering how their plans leaked out :)
Hey - this looks great !!
But it's not all good. Although the code is elegant and intuitive, it actually generating a MyFixture.designer.cs file, with all the ugly stuff hidden there.
Comment preview