Working Around BehaviorNotImplementedException When Instantiating Stubs

I got this exception in this morning, but thankfully there is a workaround. Do not despair!

Assume the following code. In the Concrete class we have a global level _internalString field and the virtual TestString property with returning the string literal “Pex Is Pissing Adam Off!” (as it was this morning!) in the Concrete base class constructor we are simply backing field settings, nothing amazing. Yeah the virtual member call in the concrete class constructor is bad since it will cause the most derived override to be called, even though the most derived constructor has not been fully run yet (may not be in a suitable state to have that method called). But bah! It’s part of the code and it’s not like that warning isn’t already thrown in nearly every SharePoint artifact.

Anyways, so in the rest of the code there is nothing amazing that is happening, as you can see the class containment hierarchy is using the Concrete base class for the child Superclass derived class, which is just overriding a simple property.

[csharp]
namespace AdamHatingPex
{
public class Concrete
{
private string _internalString;
public virtual string TestString{ get { return “Pex Is Pissing Adam Off!”; } }
public Concrete()
{
_internalString = TestString;
}
}
public class SuperClass : Concrete
{
public override string TestString
{
get { return “But I’ll Get Over It”; }
}
}
}
[/csharp]

Assuming this code, if you stub out the derived class you are going to get a Microsoft.Moles.Framework.Behaviors.BehaviorNotImplementedException error, as you can guess since it’s the only thing in the class it occurs on the overridden property. Quick hint, using CallBase with your call won’t help since base constructors should be run before derived ones (going back to what was discussed previously).
However, it is solvable by changing the behavior. I am not going to get into behaviors yet but you can adjust behavior pre-instantiation of the stub and let it Fall Through or Default Provide A Value. By default the instance will use the BehavedBehaviors.Current property, which will by default throw a BehavedBehaviors.NotImplemented. You can switch this around by setting the InstanceBehavior property on any stub instance. This is pretty easy, demonstrated below:

[csharp]
BehavedBehaviors.Current = BehavedBehaviors.Fallthrough;
var x = new Test.Moles.SSuperClass();
[/csharp]

When you are done with your stuff, you can return to default behavior:

[csharp]
BehavedBehaviors.Current = BehavedBehaviors.NotImplemented;
[/csharp]

If you are interested in this, you should look into the [assembly: PexChooseAsBehavedBehavior] attribute further as well.

Share

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!

Share

Remember DateTime Casting With SP.ListItem Modified Property

I had this come up with a client this morning. To get down with it, consider the following client object model code:

[csharp]
ClientContext clientContext = new ClientContext(“http://test”);
List list = clientContext.Web.Lists.GetByTitle(“TestList”);
ListItemCollection listItems = list.GetItems(CamlQuery.CreateAllItemsQuery());
ListItem item = listItems[0];

// pay attention to this!
DateTime modifiedDate = (DateTime)item[“Modified”];

// Should use include to only use the properties that are required
clientContext.Load(item);
clientContext.ExecuteQuery();

[/csharp]

In the above we have a couple things going on. Firstly, a ClientContext object is instantiated to represent the context for SharePoint objects and operations. Next, we are getting a SP.List object by using the ListCollection.GetByTitle method passing in the list name. Next, we are getting all the items from the list by using the SP.List.GetItems method then passing in the CamlQuery.CreateAllItemsQuery method. Indexing the collection, we are getting a test SP.ListItem. Now this is where the context of this post comes into play. If you are getting the Modified property of the list item, you have to remember to explicit cast to a DateTime type (you could safely cast as well). If you don’t, the value **may** display empty (it’s not consistent across list types)!

Share