Mocking support in Microsoft Velocity

by Alex Meyer-Gleaves 3 June 2009 - 2:06 AM

I have been looking at the Microsoft Distributed Cache and have found the been fairly impressed with the project. The download page offers a brief description of “Velocity”:

"Velocity" is a distributed in-memory application cache platform for developing scalable, high-performance applications. "Velocity" can be used to cache any common language runtime (CLR) object and provides access through simple APIs. The key aspects of "Velocity" are distributed cache performance, scalability, and availability.

Being a fan of TDD (Test-Driven Development) and mocking in my unit tests I was keen to see how well the API supported mocking. It turns out that the support for mocking is no where to be found. None of the classes implement interfaces and the important methods that support general caching operations are not virtual. Looking at the sample code below you can see how not having an IDataCache interface on the DataCache class will make unit testing the CustomerRepository class in isolation difficult. Even though the DataCache instance is passed into the constructor the interaction with it cannot be mocked.

public class CustomerRepository : ICustomerRepository
{
    private readonly DataCache _dataCache;

    public CustomerRepository(DataCache dataCache)
    {
        _dataCache = dataCache;
    }

    public Customer GetCustomer(int customerId)
    {
        Customer customer = (Customer)_dataCache.Get(customerId.ToString());
        if (customer == null)
        {
            customer = // Code that gets customer from the database.
            _dataCache.Put(customerId.ToString(), customer);
        }
        return customer;
    }
}

The idea of having my unit tests dependant on a running cache service is certainly not attractive, and while it would be possible to wrap the classes and provide an interface implementation of my own, this is not an attractive option either. The support for unit testing is now expected in the design of an API and Microsoft should be providing this for something as core as an application cache. I hope that the team at Microsoft sees this as a problem and provides some interfaces, or at very least makes the methods that support the primary caching operations virtual.

Tags:

Categories: Microsoft .NET

Comments

10/4/2009 9:51:53 PM #

Tim Ellison

Hi Alex.

Regarding TDD and Velocity, I would think that mocking Velocity would not be of much value.  Rather, wrap Caching with an interface and VelocityCache becomes one of the concrete implementations.  Just my two cents.

Also, look to Unity or Spring.NET and consider using Caching as an aspect rather than embedded in code.  We have embraced AOP and found it to be much more robust than hardwiring caching in the application.  

Tim Ellison United States |

10/5/2009 6:40:10 AM #

Alex Meyer-Gleaves

Hi Tim,

I mention creating a caching interface and wrapping the implementation as being an unattractive option in my post mostly because of how I wanted to use Velocity. For simple caching requirements creating your own interface is obviously the way to go, and is in fact the strategy we are currently using. My issue was that I was interested in using a wide range of the features Velocity provides (locking, notifications, tagging etc.), and after looking at building my own caching interface realised that it would become fairly extensive and start looking similar to that of Velocity anyway. I was just a little surprised that given the inroads Microsoft has made with testability in their API design (e.g. ASP.NET MVC) that Velocity did not follow this trend.

I have been using Autofac for my dependency injection requirements for a long time now and have grown so comfortable with it that I tend to include in my stack as a given. The delegate based registration in Autofac had me hooked, and when Unity came out it didn’t provide any new features to make me want to change. In regards to AOP I have been using PostSharp, but I need go back and have another look at AspectSharp. I totally agree that caching is a great candidate for AOP. If you get the opportunity to implement Velocity I would love to hear about your experiences.

Thanks for the feedback, I really appreicate it.

Cheers,

Alex.

Alex Meyer-Gleaves Australia |

Comments are closed

About the author

Alex Meyer-Gleaves I'm a software developer living in Australia (that island like continent in the southern hemisphere). I love Microsoft .NET and C#. I hate early mornings, slow drivers and Lotus Notes.

Google Reader Clips

SpringWidgets
RSS Reader
This widget is the staple of our platform. Read all your feeds right here with thisone widget - Supported feeds are OPML, RSS, RDF, ATOM. Watch your favorite Podcastin the embedded Video Player on the Desktop or publish your own video playlist toyour site for others to view!

Recent Comments

Comment RSS

Links

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in  anyway.

© Copyright 2008