If you're serious about testing before long you'll bump into the need to do some mocking. You can of course chose to write your own mocks but that is hardly time effective or trivial.  More than likely you'll want to use a framework, but how do you choose between the most popular options?

There's been some discussion on Twitter between myself and Daniel Cazzulino(@kzu), the creator of Moq (pronounced "Mock-you" or just "Mock"), a newer and popular .NET mocking, about mocking frameworks and what goes into choosing a mocking framework.  Daniel and I share a passion in mocking and by extension testing.  As the creator of Moq, I hold him in very high regard.

The discussion centered around some work that Andrew Kazyrevich has been doing recently.  Andrew is passionate about mocking.  As such he's created an open source project which compares the "big dawgs" of .NET mocking frameworks.  In his introductory post he explains the intent, which is message I support and want to help spread:

I've started a small open source project. It provides a unified set of tests written against Moq, NMock2, Rhino Mocks and Typemock Isolator, so that you can easily compare the frameworks and make an informed decision when picking one up.

In Andrew's most recent post he compares the execution time of the various frameworks.  My response on the RhinoMocks mailing list was terse but sincere:

Curious about speed in your tests, is the a first level concern when choosing a testing framework?

Daniel answered the question in a tweet:

IMO, API design, usability and expressiveness is a much more valuable comparison. #moq is not optimized for runtime perf.

To which I responded:

I would also throw in documentation, discoverability, and community into your equation.

So, fine blog reader, I have a question for you.  If you are using a mocking framework, what are your first-level concerns when you chose your framework?  For those who have yet to utilize a framework, what will you base your decision on when you do choose?

• Execution Speed
• API Design
• Usability
• Expressiveness
• Documentation
• Discoverability (possibly coincides with API Design)
• Community
• Other?

People sometimes ask how to get involved in open source software.  In fact Scott Hanselman posted on a the subject in great detail over two years ago when detailed how you could submit a patch to an open source project.  Good intentions aside, getting involved at the source code level of a mature open source project can be quite daunting. There is a often large, hopefully active, codebase which you might not be too familiar with. Despite your sincere interest in contributing, often the startup "cost" is too great and you find that there is a sense of hopelessness in achieving that goal.  It really doesn't have to be this way.

I'd like to suggest that a great way to getting started with open source is getting involved in the mailing list for a project by answering questions posted by the community.  Nearly all, if not all, of the open source projects I use have either a forum or a mailing list associated with them.

My History in Open Source

Despite my use and open support of open source software I have to date only submitted 2.5 patches to the open source community (the 1/2 patch was me assisting in writing a RegularExpression for the developer who was actually writing the meat of the patch).  Despite my best intentions, I have yet to know an open source codebase well enough in my opinion to submit substantive contributions to the project, so I do my best to contribute in other ways.

I am currently an active participant on the RhinoMocks mailing list where I try to provide answers and guidance on RhinoMocks and testing in general.  When I made the decision to start contributing on the list, my goal was simply to beat Ayende every once in awhile to the answer...seriously, the guy is fast. As I've spent some time on the list I've become more comfortable answering questions and I've seen others jump in and help as well.  I like to think that I'm contributing to the project as a whole, if only by answering questions posed by other users of the framework. Often times, in the absence of others to assist, answering questions falls to the contributors of the project which takes away from the time they would have to further the development of the project.

If you've had a desire or an interest in getting involved and you aren't comfortable contributing via source code, think about getting involved with a project you already use and are familiar with.  Subscribe to the forum and mailing list and challenge yourself to answer a single question, then two or three. I think you'll find that the managers of these projects will be very appreciative of the help!

I want to invite any of you who are within a few hours of Des Moines, Iowa to attend the second Iowa Code Camp on November 8th.  The first Iowa Code Camp back in May was a huge success. From Derik's write-up:

Yesterdays event was awesome.  They had about 125-150 people show up for the first ever Code Camp in Iowa.  The venue could not have been any nicer and setup any better.

I will be giving one presentation on using RhinoMocks and one workshop on TDD.  Below are the abstracts.  If you have the chance, take part, and register today.

TDD: A Workshop in Driving Your Design with Tests

If you've heard about Test Driven Development (TDD) and wondered what it was or how to do it, then this workshop is for you.  We'll take a practical, introductory approach to getting started with TDD.  We'll introduce fundamental object-oriented design principles including separation of concerns, dependency injection/inversion, and more.  This will be a hands on lab, so bring your laptops and a copy of Visual Studio 2008 and expect to learn.

Easing your Testing With RhinoMocks

When learning about testing you'll see trivial examples illustrating how to write tests. However most production code is non-trivial, making calls to configuration files or to a database which makes testing in isolation hard.  The use of mock objects allows you to isolate code you want to test by providing fake objects to your methods, allowing you to set up complex scenarios to test specific conditions.  In this session we'll first dig into some code that is not very testable and refactor it to make it more testable.  After the refactoring we'll use and explore RhinoMocks to see how we can test different scenarios in our code and verify our code is working as it should.

Yesterday Oren announced the release of RhinoMocks 3.5.  While the RC version has been out for a bit the RTM release fixes a few bugs.  You can read all about the enhancements and features in Oren's post. 

The feature that excites me the most about the new RhinoMocks release is the AAA Syntax (Arrange-Act-Assert).  One thing I've always struggled with when explaining mocking to people is the record replay model.  The new syntax seems to be more natural.  I have no empirical evidence to back that last statement up, only anecdotal evidence from observing fellow employees interact with the new syntax.

A close second in terms of changes is the deprecations of CreateMock().  In all the features, patches, improvements, and bug fixes this is the only item Oren bolded, which shows it's importance:

CreateMock() is deprecated and marked with the [Obsolete] attribute. Use StrictMock() instead.

This one is great for beginners who instinctively pick up the binaries and see the method CreateMock() and end up later with brittle tests.  Brad Abrams talks about the "Pit of Success" and quotes Rico Mariani:

The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail.

In earlier versions of Rhino it was too easy to use CreateMock() when DynamicMock() is what you wanted.  New mockers were often using the wrong method (I was one of these CreateMock() abusers/users).  The warning when using CreateMock, and the other enhancements/changes, make falling into the pit of success (with mocking) a much more likely reality.

You can download the bits from Oren's download area.  When you download, I would encourage you to make a donation to Oren's open source efforts.