Using wrappers to aid unit testing

As I alluded to about recently when blogging about JustMock, one of the most important attributes of unit tests has to be that they are readable; you can easily reason about them and see what they do.

I also talking about Moq’s overly cumbersome and verbose approach to performing Setups on mocks – I rarely supply arguments for setup methods on mocks, since this would be doing two tests in one i.e. mocking that we handling the result of the method, but also implicitly testing that we called the method with the correct arguments. The latter should be left for another test.

Coincidentally, I had a look at a few other frameworks recently: –

  • FSUnit, which is an F# unit testing framework that wraps around NUnit / MSTest / XUnit etc. to provide a more succinct unit test experience in F#
  • Simple.Data, which is an awesome data access layer that works over multiple data sources and uses C#’s dynamic feature to allow you to very easily generate queries etc. against data sources with the minimum of fuss.

Simplifying Moq’s Setup

This got me thinking – could we not do the same with mocking frameworks? Well, a couple of hours later, the answer is yes. Here’s a simple example of how you can set up mocks in Moq much more succinctly using a dynamic wrapper class. First the original Moq Setup method: –

public void Foo_GotPayroll_LogsIt()
    service.Setup(svc => svc.GetPayroll(It.IsAny<Person>(), It.IsAny<Person>(), It.IsAny<Person>())).Returns("ABCDEFG");

    // Act
    classUnderTest.Foo(null, null, null);

    // Assert
    logger.Verify(l => l.Log("Got back ABCDEFG."));

Notice the large amount of noise from the It.IsAny<T>() calls – almost 50% of the contents of the statement are taken up by It.IsAny().

Now look at this version: –

public void TestFoo()

    // Act
    classUnderTest.Foo(null, null, null);

    // Assert
    logger.Verify(l => l.Log("Got back ABCDEFG."));

It uses an new extension method of Setup which operates slightly differently: –

  1. It returns a dynamic object which when called immediately seeks out any method on the mock service that are called “GetPayroll”.
  2. It then filters out any overloads that do not have the matching return type of System.String.
  3. Then, for each matched method, it parses the argument list and generates an expression which calls the method, with an appropriate It.IsAny<T>() call for every argument.

In effect, it expands into the code of the first version, but at runtime. Notice how much more succinct the code is – you don’t need to waste time with It.IsAny<T>(), or call IgnoreArguments(), or even with the lambda expression – you simply provide the name of the method you want to mock out as a parameterless method call – which is what your intent is anyway – and then call Returns on it.

You can also do the same with Throws, which will take in an Exception and setup a Moq call to .Throws(). Easy.


This was more an experiment to see how easy it would be to create a more succinct wrapper around Moq (I’ll put the source code up for anyone that wants it) but also to see whether it would actually work from a consumption point of view – does it feel “right” to call a dynamic method which does setup / mocking for you? Can you have confidence in it? I leave that you to to decide 🙂

Performance or readability with Expression Trees in C#

I was fumbling around trying to create some expression trees on Friday and was working through some stuff with a colleague of mine (someone who actually knows how to do it better than me!) and I got to thinking about the characteristics of different ways of doing the same things in C# with respect to both runtime performance and readability / ease of development.

Let’s say we have the following type hierarchy:


Easy enough. Now we want, for some arbitrary reason, to write a generic method that will set a specific integer property to the value of 25, but we don’t know which one it is. In our example above, that could be both the Age of the employee, or the AddressId. You could do this with reflection: –



Expression Trees

Nice. This works well, no problems whatsoever. There is another, strongly typed way of doing it though, with expression trees. By passing in an expression tree that navigates to that property, we can, at runtime, construct a Action method specific to what we want, and then call that method as needed. Here’s how we would consume such a method: –


ageSetter and addressIdSetter are two delegates that we are constructing at runtime to perform the task of setting the appropriate property to the value of 25. The main benefit of such an approach is obvious i.e. strong typing. But there’s another, more subtle benefit of such an approach – performance. To understand why this is, we need to understand how this method is implemented.

CreatePropertySetter returns an Action<T> which, when called, will set the appropriate property to 25: (I’ve elided the GetMembersEnumerator method for clarity)


To make it a bit easier to see what happens, when we call the method with e => e.Age, here’s what the above method looks like with debugger quickwatches pinned: –


By compiling the final expression, we get a proper Action method which is the same as instance => instance.Age = 25, except we’ve constructed this code, at runtime.

I find Expression Trees difficult to get my head around. I understand the idea of them – essentially building up a tree of things like “assign property” and “call method” and “if” etc. which can then be compiled into a lambda. But the Expression API has lots of factory methods and many ways to do the same thing; I guess with time you gain familiarity with the API, but it’s definitely not the easiest thing in the world to get your head around. Worse still, look at the code required to do the same thing as that reflection code – much more effort and much less readable.

However, where performance is concerned, Expression Trees will beat Reflection by miles – as long as you cache the Action method that is generated! The construction and parsing of the expression trees required to create the Action is an expensive operation, so you should cache the Actions. Once you’ve done that, the cost is extremely low, as you are simply calling an action method, almost the same as if you had written it yourself. For example, to set both the Age and AddressId properties to 25, for 2.5 million Employees, I observed the following timings: –

Type of code applied Time required (ms)
Direct assignment




Expression Trees




Hard-coded lambdas


Obviously the other three options wouldn’t be appropriate for the problem at hand (generic property assignment) but I wanted to illustrate how these two mechanisms performed. By the way – notice how much quicker dynamic is than reflection (and these timings were obtained when caching the property info objects as well). Funnily enough, if I wrote hard coded lambdas e.g. instance => instance.Age = 25 and used them, they outperformed code like instance.Age = 25. Why?


When you next use reflection for some property assignments or method calls, think about using Expression Trees, particularly where performance is a factor. Expression Trees are time consuming to write and understand, but offer superior performance and can be consumed in a strongly-typed manner. Alternatively, consider the use of dynamic where possible – again, for property setters and getters and method calls it offers better performance than reflection, and whilst obviously not strongly-typed, the code is again far more readable.

When to use C#’s dynamic type?

The scenario

You have a set of large set (say 250) of classes. You know that all those classes have a common public property on them – let’s say Id, which is an integer. Currently none of these types have any common base class, nor do they have any common interfaces. The classes are code-generated and you cannot modify them; however they are partial so you can add interfaces to them. You already have good code coverage of the rest of your system and are expected to write unit tests around any code you write.

The challenge

You need to write a method called Print that will be provided with a load of objects – say, 10,000 of them – and print their Id to the Console. This routine will be run as a batch task so performance is not an issue.

The solution

Do you: –

a) Create an interface called IIdentifiable, with a single int getter called Id. Painstakingly go through all 250 of your entities, create partial versions of them and manually put the interface on them. Writing unit tests as you go in the standard TDD approach, you code your Print method. You ensure that you only take in IEnumerable<IIdentifiable>, so you can simply iterate over the collection.

Sure, creating the interface and creating those 250 partial files might take a few hours and increase the number of files in the solution, but making the routine type-safe is the right thing to do.


b) Don’t bother with an interface – the Print method will take in IEnumerable<dynamic>. You simply pass in whatever objects you want to print out. You write a set of unit tests around the callers to that method to give you confidence that you won’t ever call the method with types that don’t have Id. As you don’t have to modify the partial classes, the method only takes about twenty minutes to code including your unit tests.

Why bother with all that faffing around with an interface for a single property when we own the code and know when we call it? Doing it this way gets the job done much quicker so I can get on with coding other features in the system.

The conclusion

Which solution would you go for? Is using dynamic here “cheating”? Is it risky? Does it indicate a bad design of your class hierarchy? Or does it indicate a willingness to pick the right tool for the job? Would it save the client that’s paying you any money? Do you care?


Another example of using C# 4 dynamic typing

Here’s a good example of where using Dynamic is handy. Imagine I want to write an all-purpose Excel reader in .NET. This reader class should be able to take in a filename and return me an object which I can use to get data out of the spreadsheet. In itself, that’s not overly difficult using e.g. OLE DB to read from the spreadsheet, but there’s always some boiler-plate involved in creating a .net object to hold the result of the query (unless you want to use DataTables throughout your application), which means you have to create a class to hold the result, and a translator of some sort to go from a DataTable to that object.

Enter the DynamicDataRow object. This handy object sits on top of a standard DataRow but allows dynamic property (column) access at runtime. You can consume it very easily: –


Obviously, we know that the shape of the data will change depending on the spreadsheet content – but don’t want the actual ExcelReader code to change with different spreadsheets.

The ExcelReader.LoadDocument code itself is very plain – it just does some simple OLE DB connection work to read the data into a bog-standard DataSet, and then returns an ExcelDocument object which takes in the DataTable containing the spreadsheet data and populates the Rows property with a DynamicDataRow object for each row in the Table. Notice that so far I’ve not discussed anything C#4 specific yet – just plain OLE DB and some properties setters etc.

In fact, the only bit of C#4 is what we enumerate over i.e. where I have “dynamic row in document.Rows”. In this case, “row” is an object of type DynamicDataRow. This is a simple class which wraps around a normal DataRow but allows direct access to properties instead of the somewhat ugly column indexer notation that you get with a DataRow: –


It’s a tiny class. All it does is inherit from DynamicObject and override the TryGetMember method to remove the need for indexer accessors and replace them with property accessors, so instead of row[“MyColumn”] you can now just do row.MyColumn. Again, though, from a client point of view, this is very easy to consume – look at the first code sample and realise that that will work for any spreadsheet whatsoever. Also notice how we treat “row” as dynamic, rather than DynamicDataRow (or object), as we want the property accessors to get intercepted by the TryGetMember method…

Can’t wait for C#4…

Following on from my posts on dynamic typing… this week I wrote a quick app to import some data from a load of XML files to a load of tables in a SQL database. The columns in the tables and the attributes in the xml file have a 1:1 mapping.

So I firstly wrote some code which goes through a given table and reads the schema from the database and creates a C# type based on the schema (using sp_columns). Then I placed a ColumnAttribute on each column etc. etc., and then goes through the task of iterating through the XML data and creating objects of that new type, copy the data across (doing the odd data type conversion along the way), and finally use the standard LinqToSql DataContext to insert the data into the DB.

But a lot of the code was somewhat ugly – messing about with TypeBuilders and FieldBuilders and the like – I’m sure that I could have done something much more elegant in C#4…. none of it was compile-time safe, it was all using reflection etc..

But it did work great anyway – apparently was used to migrate a good few thousand records of XML data into SQL relatively quickly 🙂

A Dynamic XML Document – Part 2

Continuing on from last post, how do we get the array-style [notation] on a dynamic object? Well, there’s a handy method that you can override on DynamicObject called TryGetIndex which does just that:
   1: /// <summary>

   2: /// Searches for any elements that have any attribute with the value specified.

   3: /// </summary>

   4: /// <param name="binder"></param>

   5: /// <param name="indexes"></param>

   6: /// <param name="result"></param>

   7: /// <returns></returns>

   8: public override bool TryGetIndex (GetIndexBinder binder, object[] indexes, out object result)

   9: {

  10:     var valueToSearchFor = indexes[0].ToString();

  11:     var matchingItems = GetElementsByAttributeValue (valueToSearchFor);

  12:     if (matchingItems.Any ())

  13:     {

  14:         result = new DynamicXmlDocument (matchingItems);

  15:         return true;

  16:     }


  18:     result = null;

  19:     return false;

  20: }


  22: private IEnumerable<XElement> GetElementsByAttributeValue (string attributeValue)

  23: {

  24:     var matchingItems = elements.Where (e => e.Attributes ().Any (att => att.Value == attributeValue));

  25:     return matchingItems;

  26: }


Here, I’m searching for any elements that have any attributes with a value as per specified, and then setting the result to a new dynamic xml document based on that sequence.

That’s really it, to be honest! The only things left are the Value getter, which just returns the value of the first element in the dxd, and the implementations of IEnumerable and IEnumerable <T>: –

   1: /// <summary>

   2: /// Gets the contents of the first element in this document.

   3: /// </summary>

   4: public string Value

   5: {

   6:     get { return elements.First ().Value; }

   7: }


   9: IEnumerator<DynamicXmlDocument> IEnumerable<DynamicXmlDocument>.GetEnumerator ()

  10: {

  11:     foreach (var element in this.elements)

  12:         yield return new DynamicXmlDocument (element);

  13: }


  15: IEnumerator IEnumerable.GetEnumerator ()

  16: {

  17:     foreach (var element in this.elements)

  18:         yield return new DynamicXmlDocument (element);

  19: }


I’m not that used to using the yield keyword – to be honest most collections I use day-to-day are the in-built IEnumerable<T> ones, but I see how it’s being used above (this bit is basically taken from here.

Anyway… the point being that with a relatively little amount of effort we have an object which can navigate an XML document very easily and more readably than old-style XML access, and with no real loss of type safety compared to those technologies, either.

Dynamic typing with C#4.0 part 2 – A Dynamic XML Document

Here’s a great example of where dynamic typing makes your code much more readable and logical: parsing an xml document. It turns out that someone has already done this – and I nicked a bit of his code (basically the implementation of IEnumerable) – but it’s funny how similar both of our code was before I found it (link is at end of this post).

Here’s an example XML document:


    <book id="bk101">

        <author>Gambardella, Matthew</author>

        <title>XML Developer's Guide</title>





            An in-depth look at creating applications

            with XML.



    <!-- etc. etc. -->


Now, to parse that document, you could currently use either good old XmlDocument (and / or XmlReader), or the more modern XDocument in Linq to Xml. However, both of them and still inherently weakly typed, using strings passed into methods such as “Attribute (“MyAttr”) or Element (“MyElement”). I did see an alpha demo of a strongly-typed version of a Xml Document reader a while ago but haven’t heard anything of that recently. I recall seeing that VB9 also has some good XML support, but I’m exclusively a C# coder so let’s concentrate on that 😉

Anyway. So let’s see if we can make an XML document class in C#4 which will let us read the above XML document like this:

   1: // Create our dynamic XML document based off a Linq-to-Xml XElement.

   2: var xDocument = XDocument.Load ("Example.xml");

   3: dynamic dynamicXmlDocument = new DynamicXmlDocument (xDocument.Root);


   5: // Get the first five books

   6: var books = as IEnumerable<DynamicXmlDocument>;

   7: foreach (dynamic book in books.Take (5))

   8: {

   9:     // Print out details on each book

  10:     System.Console.WriteLine ("Id: {0}, Title: {1}, Price: {2}",

  11:,            // Attribute access

  12:         book.title.Value,    // Element access

  13:         book.price.Value);  // Element access

  14: }


  16: // Get a specific book

  17: var specificBook =["bk107"];

  18: System.Console.WriteLine ("Id: {0}, Title: {1}",, specificBook.title.Value); 


  20: System.Console.Read ();

This actually wasn’t that difficult to write! Again, inheriting from DynamicObject and overriding a couple of methods, I was able to get this done in about three quarters of an hour.

First thing is the class hierarchy, our constructors and single member field:

   1: class DynamicXmlDocument : DynamicObject, IEnumerable, IEnumerable <DynamicXmlDocument>

   2: {

   3:     IEnumerable <XElement> elements;


   5:     /// <summary>

   6:     /// Creates a new instance of the XML Dynamic Document based on a single XElement.

   7:     /// </summary>

   8:     /// <param name="element"></param>

   9:     public DynamicXmlDocument (XElement element)

  10:     {

  11:         elements = new List<XElement> { element };

  12:     }


  14:     /// <summary>

  15:     /// Creates a new instance of the XML Dynamic Document based on a sequence of XElements.

  16:     /// </summary>

  17:     /// <param name="elements"></param>

  18:     public DynamicXmlDocument (IEnumerable <XElement> elements)

  19:     {

  20:         this.elements = new List<XElement> (elements);

  21:     }

Nothing too scary there, but notice how we implement IEnumerable and IEnumerable<T> so that we can do the foreach and .Take (5) in the original example.
The next bit is the first DynamicObject method we override, which gets called every time you make a property accessor request e.g. The method looks for all sub-elements that match the parameter name, and if it finds at least one, returns a new dynamic xml document (dxd) based on them. If not, it looks for any attributes in the first element of the current dxd and returns the value if it finds that. Otherwise it returns null.
   1: /// <summary>

   2: /// Gets either all children the XML Dynamic Documents (i.e. elements), or the current element's attribute.

   3: /// </summary>

   4: /// <param name="binder">Specifies the keyword to search on.</param>

   5: /// <param name="result">The resultant object.</param>

   6: /// <returns>True is a match was made.</returns>

   7: public override bool TryGetMember (System.Dynamic.GetMemberBinder binder, out object result)

   8: {

   9:     var elementNameToSearchFor = binder.Name;

  10:     var matchingChildElements = elements.Elements (elementNameToSearchFor);

  11:     if (matchingChildElements.Any())

  12:     {

  13:         result = new DynamicXmlDocument (matchingChildElements);

  14:         return true;

  15:     }


  17:     var attributeNameToSearchFor = binder.Name;

  18:     var attribute = elements.First ().Attribute (attributeNameToSearchFor);

  19:     if (attribute != null)

  20:     {

  21:         result = attribute.Value;

  22:         return true;

  23:     }


  25:     result = null;

  26:     return false;

  27: }


The next question is how to get that array notation e.g. book[“123”] as per the example? That’ll be answered in the next post!