Understanding The Big Difference Between Stubs And Moles

I am still retrofitting a whole bunch of unit tests at a client using Pex and Moles. As we have seen in past posts, Pex and Moles are great for creating parameterized unit tests and mock data!

In a conference call this morning, it got brought up that similar to other mocking products in SharePoint development, why all the classes are just not moled (I still don’t know if this is the right verbiage!) and why the heck I am using so many stubs :) . It turned into a lengthy discussion that I wanted to sum up so I can point to this post later!

Firstly, a stub (or more accurately, the stubs framework) is basically a nifty means of static code generation. What this means is a dissimilarity in expectation structured expression trees for testing (the code is generated at runtime [dynamic]). Now, stubs find utility because of efficiency and declarative coverage, the performance benefits coming from the leveraging of virtual method dispatch. Virtual method dispatch is generally more efficient since it already has the this pointer ready to go. When calling through a delegate the this pointer has to be fetched from the delegate. Booooo hisssssss. :) So it’s fast! In the terms of components, Moles lean on the CLR (the profiler more specifically) for the test generation, whereas stubs will use the virtual method approach to overload stuff.

Now, even though the efficiency is pretty impressive, this indubitably doesn’t mean that stubs should continually be used over moles. That is best established by what exactly is being tested. So approach may heavily vary. But, a rule of thumb is if you can use stubs, suck it up, deal with the code bloat, and enjoy the performance benefits! It is always important to still consider what you are testing however, you want to make sure that the unit testing is targeted and is not inadvertently testing unnecessary classes and promotes proper testing!


SharePoint ECMAScript (Client Object Model) Empty List Helper

Lists are a lot more useful as data storage mechanisms in SharePoint 2010 since there are important relational features finally built into them. Coupled with the client object model features you can start to do some really nifty data manipulation with some quick, easy code. As such, I have been starting to build up a bunch of bulk list operations that I’m using in a static manner for both some internal as well as client applications.

In the below helper function, I am emptying the items out of a list. It’s actually probably better to abstract the list title to the emptyListHelper parameters so you can pass in a string in a shared manner, so that’s might be a good idea.

var siteUrl = ‘/AdamBuenz/EmptyItemsTest’;

function emptyListHelper() {
var clientContext = new SP.ClientContext(siteUrl);
var list = clientContext.get_web().get_lists().getByTitle(‘TestList’);
var camlQuery = new CamlQuery();
camlQuery.set_viewXml(“Some Value To Match Value100“;
this.listItems = list.GetItems(camlQuery);
clientContext.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded), Function.createDelegate(this, this.onQueryFailed));

function onQuerySucceeded() {
var listItemEnumerator = this.listItems.getEnumerator();
while (listItemEnumerator.moveNext()) {
var item = listItemEnumerator.get_current();

function onQueryFailed(sender, args) {
alert(‘Request failed. ‘ + args.get_message() + ‘\n’ + args.get_stackTrace());



Take Advantage of Lambdas with RunWithElevatedPrivileges

One of the compelling features in C# 3.0 is the presentation of lambda expressions, cultivated out of the anonymous delegate (type-safe function pointers) support (don’t need to define a method somewhere else) that was present in C# 2.0. A lambda expression organizes with a left side composed of the arguments and a right expression which is the body of the method, split with a =>.

In the context of SPSecurity.RunWithElevatedPrivileges to encourage execution of a method with Full Control rights, it is common to see it as an anonymous method. For example, when using the SPUtility.SendEmail method it is ordinary to elevate rights. Using pre C# 3.0 mechanisms this would normally take on the form:
SPUtility.SendEmail(SPContext.Current.Site.OpenWeb(), false, false, “no_reply@sharepointsecurity.com”, “this is my subject”, “this is my body”);

This is a fair amount of real estate on the code surface. Wouldn’t it be nicer if we introduced a little bit of syntax sugar to tidy it up? This is where lambda expressions are accommodating. Taking the above method, this instead takes on the form:
SPSecurity.RunWithElevatedPrivileges(() => SPUtility.SendEmail(SPContext.Current.Site.OpenWeb(), false, false, “no_reply@sharepointsecurity.com”, “this is my subject”, “this is my body”));
This is much cleaner, and required less typing!