I notice that James Whittaker finally started blogging in July. He recently blogged on STARwest, including describing Keith Stobie as “10 testers in one”. I would have to agree having spent the last day at STARwest at “California Adventure” (the park across the way from Disneyland) with Keith, talking testing and other topics as we queued for rides. It was my first testing talking day for a while .

As James started blogging, my blogging fell in a hole, but hopefully it is now back…. I got to have several dodgy quality experiences at Disneyland and California Adventure and at other places (some self inflicted!), that will either be blog entries or talk fodder in the coming year….. I may even tell some other STARwest stories as well, the lightning talk that became a full session that became a keynote, or the STARwest lightning talk that was going to have James Whittaker testing software disguised as Darth Vader!!!!! Stay tuned!

In any unit testing activity, there always comes a point when one needs to isolate the code under test from the environment. This usually involves adding interfaces at the environment boundaries, which can be used to test the code in isolation. Because implementing those interfaces ‘by hand’ for the test can be tedious, an ecosystem of mock frameworks has flourished (NMock, Rhino Mocks, Moq, there’s more…). In fact, it’s a pretty competitive area.

The dark side of Mocks frameworks

Under their friendly API, mock frameworks usually hide a complex machinery: dynamic code (through Reflection.Emit or a rewriting profiler), expression trees or reflection.

From a Pex point of view, this ‘machinery’ puts a large burden on the dynamic whitebox code analysis; Pex does a precise data flow and control analysis for any code that is executed, this means that it also has to analyze the mock infrastructure.  

Therefore, we decided to build a framework to define stubs that would try to avoid the overhead of dynamic code generation (just rely on source code) and still provide the same level of flexibility of existing mock frameworks: defining the behavior of the stub inside the test, strongly typed, intellisense support, first-class debugging experience, etc…

Low tech Stubs using delegates

With C# 3.0 lambdas, it is quite easy to define delegates. Therefore, delegates seemed an elegant and simple way for building stub methods (we’re not the first ones to think about this). For example, a stub of the IServiceProvider would simply be

class SServiceProvider : IServiceProvider {
    // this field can be set to ‘override’ the behavior of GetService
    public Func GetServiceHandler;
    object IServiceProvider.GetService(Type type) {
        var d = this.GetServiceHandler;
        if (d != null) return d(type); // i’m stubbed :)
        else throw new NotImplementedException();
    }
}