ploeh blog danish software design

One of the first sound bites from the beloved book Design Patterns is this:

Program to an interface, not an implementation

It would seem that a corollary is that we can measure the quality of our code on the number of interfaces; the more, the better. However, that's not how it feels in reality when you are trying to figure out whether to use an IFooFactory, IFooPolicy, IFooPolicyFactory or perhaps even an IFooFactoryFactory.

Do you extract interfaces from your classes to enable loose coupling? If so, you probably have a 1:1 relationship between your interfaces and the concrete classes that implement them. That's probably not a good sign, and violates the Reused Abstractions Principle (RAP). I've been guilty of this and didn't like the result.

Having only one implementation of a given interface is a code smell.

Programming to an interface does not guarantee that we are coding against an abstraction. Interfaces are not abstractions. Why not?

An interface is just a language construct. In essence, it's just a shape. It's like a power plug and socket. In Europe we use one kind, and the US uses another, but it's only by convention that we transmit 230V through European sockets and 110V through US sockets. Although plugs only fit in their respective sockets, nothing prevents us from sending 230V through a US plug/socket combination.

Krzysztof Cwalina already pointed this out in 2004: interfaces are not contracts. If they aren't even contracts, then how can they be abstractions?

Interfaces can be used as abstractions, but using an interface is in itself no guarantee that we are dealing with an abstraction. Rather, we have the following relationship between interfaces and abstractions:

There are basically two sets: a set of abstractions and a set of interfaces. In the following we will discuss the set of interfaces that does not intersect the set of abstractions, saving the intersection for another blog post.

There are many ways an interface can turn out to be a poor abstraction. The following is an incomplete list:

LSP Violations #

Violating the Liskov Substitution Principle is a pretty obvious sign that the interface in use is a poor abstraction. This may be most obvious when the consumer of the interface needs to downcast an instance to properly work with it.

However, as Uncle Bob points out, even an interface as simple as this seemingly innocuous rectangle ‘abstraction' contains potential dangers:

public interface IRectangle
{
    int Width { get; set; }
    int Height { get; set; }
}

The issue becomes apparent when you attempt to let a Square class implement IRectangle. To protect the invariants of Square, you can't allow the Width and Height properties to differ. You have a couple of options, none of which are very good:

• Update both Width and Height to the same value when one of them are being written.
• Ignore the write operation when the caller attempts to assign an invalid value.
• Throw an exception when the caller attempts to assign a Width which is different from the Height (and vice versa).

From the point of view of a consumer of the IRectangle interface, all of these options would at the very least violate the Principle of Least Astonishment, and throwing exceptions would definitely cause the consumer to behave differently when consuming Square instances as opposed to ‘normal' rectangles.

The problem stems from the fact that the operations have side effects. Invoking one operation changes the state of a seemingly unrelated piece of data. The more members we have, the greater the risk is, so the Interface Segregation Principle can, to a certain extent, help.

Header Interfaces #

Since a higher number of members increases the risk of unexpected side effects and temporal coupling it should come as no surprise that interfaces mechanically extracted from all members of a concrete class are poor abstractions.

As always, Visual Studio makes it very easy to do the wrong thing by offering the Extract Interface refactoring feature.

We call such interfaces Header Interfaces because they resemble C++ header files. They tend to simply state the same thing twice without apparent benefit. This is particularly true when you have only a single implementation, which tends to be very likely for interfaces with many members.

Shallow Interfaces #

When you use the Extract Interface refactoring feature in Visual Studio, even if you don't extract every member, the resulting interface is shallow because it doesn't recursively extract interfaces from the concrete types exposed by the extracted members.

An example I've seen more than once involves extracting an interface from a LINQ to SQL or LINQ to Entities context in order to define a Repository interface. As an example, here's an interface extracted from a very simple LINQ to Entities context:

public interface IPostingContext
{
    void AddToPostings(Posting posting);
    ObjectSet<Posting> Postings { get; }
}

At first glance this may look useful, but it isn't. Even though it's an interface, it's still tightly coupled to a specific object context. Not only does ObjectSet<T> reference the Entity Framework, but the Posting class is defined by a very specific, auto-generated Entity context.

The interface may give you the impression of working against loosely coupled code, but you can't easily (if at all) implement a different IPostingContext with a radically different data access technology. You'll be stuck with this particular PostingContext.

If you must extract an interface, you'll need to do it recursively.

Leaky Abstractions #

Another way we can create problems for ourselves is when our interfaces leak implementation details. A good example can be found in the SystemWrapper project that provides extracted interfaces for various BCL types, such as System.IO.FileInfo. Those interfaces may enable mocking, but we shouldn't expect to ever be able to create another implementation of SystemWrapper.IO.IFileInfoWrap. In other words, those interfaces aren't very useful.

Another example is this attempt at defining a Repository interface:

public interface IFooRepository
{
    string ConnectionString { get; set; }
    // ...
}

Exposing a ConnectionString property strongly indicates that the repository is implemented on top of a database; this knowledge leaks through. If we wanted to implement the repository based on a web service, we might be able to repurpose the ConnectionString property to a service URL, but it would be a hack at best - and how would we define security settings in that scenario?

Exposing a FileName property on an interface that represents an abstract resource is another example of a Leaky Abstraction.

Leaky Abstractions like these are often difficult to reuse. As an example, it would be difficult to implement a Composite out of the above IFooRepository - how do you aggregate a ConnectionString?

Conclusion #

In short, using interfaces in no way guarantees that we operate with appropriate abstractions. Thus, the proliferation of interfaces that typically follow from TDD or use of DI may not be the pure goodness we tend to believe.

Creating good abstractions is difficult and requires skill. In a future post, I'll look at some principles that we can use as guides.

Comments

Back in the days of AutoFixture 1.0 I occasionally got the feedback that although people liked the engine and its features, they didn't like the data it generated. I think they particularly didn't like all the Guids, but Håkon Forss suggested combining Object Hydrator's data generator with AutoFixture.

In fact, this suggestion made me realize that AutoFixture 1.0's engine wasn't extensible enough, which again prompted me to build AutoFixture 2.0. Now that AutoFixture 2.0 is out, what would be more fitting than to examine whether we can do what Håkon suggested?

It turns out to be pretty easy to customize AutoFixture to use Object Hydrator's data generator. The main part is creating a custom ISpecimenBuilder that acts as an Adapter of Object Hydrator:

public class HydratorAdapter : ISpecimenBuilder
{
    private readonly IMap map;
 
    public HydratorAdapter(IMap map)
    {
        if (map == null)
        {
            throw new ArgumentNullException("map");
        }
 
        this.map = map;
    }
 
    #region ISpecimenBuilder Members
 
    public object Create(object request,
        ISpecimenContext context)
    {
        var pi = request as PropertyInfo;
        if (pi == null)
        {
            return new NoSpecimen(request);
        }
 
        if ((!this.map.Match(pi))
            || (this.map.Type != pi.PropertyType))
        {
            return new NoSpecimen(request);
        }
 
        return this.map.Mapping(pi).Generate();
    }
 
    #endregion
}

The IMap interface is defined by Object Hydrator, ISpecimenBuilder and NoSpecimen are AutoFixture types and the rest are BCL types.

Each HydratorAdapter adapts a single IMap instance. The IMap interface only works with PropertyInfo instances, so the first thing to do is to examine the request to figure out whether it's a request for a PropertyInfo at all. If this is the case and the map matches the request, we ask it to generate a specimen for the property.

To get all of Object Hydrator's maps into AutoFixture, we can now define this customization:

public class ObjectHydratorCustomization :
    ICustomization
{
    #region ICustomization Members
 
    public void Customize(IFixture fixture)
    {
        var builders = from m in new DefaultTypeMap()
                        select new HydratorAdapter(m);
        fixture.Customizations.Add(
            new CompositeSpecimenBuilder(builders));
    }
 
    #endregion
}

The ObjectHydratorCustomization simply projects all maps from Object Hydrator's DefaultTypeMap into instances of HydratorAdapter and adds these as customizations to the fixture.

This enables us to use Object Hydrator with any Fixture instance like this:

var fixture = new Fixture()
    .Customize(new ObjectHydratorCustomization());

To prove that this works, here's a dump of a Customer type created in this way:

{
  "Id": 1,
  "FirstName": "Raymond",
  "LastName": "Reeves",
  "Company": "Carrys Candles",
  "Description": "Lorem ipsum dolor sit",
  "Locations": 53,
  "IncorporatedOn": "\/Date(1376154940000+0200)\/",
  "Revenue": 33.57,
  "WorkAddress": {
    "AddressLine1": "32373 BALL Lane",
    "AddressLine2": "29857 DEER PARK Dr.",
    "City": "fullerton",
    "State": "NM",
    "PostalCode": "27884",
    "Country": "GI"
  },
  "HomeAddress": {
    "AddressLine1": "66377 NORTH STAR Pl.",
    "AddressLine2": "33406 MAY Dr.",
    "City": "miami",
    "State": "MD",
    "PostalCode": "18361",
    "Country": "PH"
  },
  "Addresses": [],
  "HomePhone": "(388)538-1266",
  "Type": 0
}

Without Object Hydrator's data generators, this would have looked like this instead:

{
  "Id": 1,
  "FirstName": "FirstNamebf53cb4c-3aae-4963-bb0c-ad0219293736",
  "LastName": "LastName079f7ab2-d026-48c5-8cfb-76e0568d1d79",
  "Company": "Company9ffe4640-2534-4ef7-b066-fb6bbe3a668c",
  "Description": "Descriptionf5843974-b14b-4bce-b3cc-63ad6aaf3ab2",
  "Locations": 2,
  "IncorporatedOn": "\/Date(1290169587222+0100)\/",
  "Revenue": 1.0,
  "WorkAddress": {
    "AddressLine1": "AddressLine1f4d50570-423e-4a74-8348-1c54402ffe48",
    "AddressLine2": "AddressLine2031fe3e2-40c1-4ec3-b445-e88c213457e9",
    "City": "Citycd33fce3-66bb-457d-8f99-98a16c0c5bf1",
    "State": "State40bebd6d-6073-4421-8a74-e910ff9d09e3",
    "PostalCode": "PostalCode1da93f22-799b-4f6b-a5ce-f4816f8bbb05",
    "Country": "Countryfa2ad951-ce0c-42a4-ab55-c077b6e03f00"
  },
  "HomeAddress": {
    "AddressLine1": "AddressLine145cbffeb-d7a9-4778-b297-d010c30b7614",
    "AddressLine2": "AddressLine2e86d6476-5bdc-4940-a8ee-975bf3f65d49",
    "City": "City6ae3aab9-7c73-4768-ae7d-a6ea515c816a",
    "State": "State56de6222-fd84-46b0-ace0-c6098dbd0681",
    "PostalCode": "PostalCodeca1af9af-a97b-4966-b156-cfbebd6d5e38",
    "Country": "Country6960eebe-fe6f-4b63-ad73-7ba6a2b95791"
  },
  "Addresses": [],
  "HomePhone": "HomePhone623f9d6f-febe-4c9f-87f8-e90d7e57eb46",
  "Type": 0
}

One limitation of Object Hydrator is that it requires the classes to have default constructors. AutoFixture doesn't have that constraint, and to prove that I defined the only available Customer constructor like this:

public Customer(int id)

With AutoFixture, this is not a problem and the Customer instance is created as described above.

With the extensibility model of AutoFixture 2.0 I am pleased to be able to verify that Håkon Forss (and others) can now have the best of both worlds :)

Comments

AutoFixture now includes a Rhino Mocks-based auto-mocking feature similar to the Moq-based auto-mocking customization previously described.

The developer of this great optional feature, the talented but discreet Mikkel has this to say:

"The auto-mocking capabilities of AutoFixture now include auto-mocking using Rhino Mocks, completely along the same lines as the existing Moq-extension. Although it will not be a part of the .zip-distribution before the next official release, it can be built from the latest source code (November 13, 2010) which contains the relevant VS2008 solution: AutoRhinoMock.sln. It is built on Rhino.Mocks version 3.6.0.0. To use it, add a reference to Ploeh.AutoFixture.AutoRhinoMock.dll and customize the Fixture instance with:

var fixture = new Fixture()
    .Customize(new AutoRhinoMockCustomization());

"which automatically will result in mocked instances of requests for interfaces and abstract classes."

I'm really happy to see the AutoFixture eco-system grow in this way, as it both demonstrates how AutoFixture gives you great flexibility and enables you to work with the tools you prefer.

Garth Kidd was so nice to point out to me that I hadn't needed stop where I did in my previous post, and he is, of course, correct. Taking a dependency on an Abstract Factory that doesn't take any contextual information (i.e. has no method parameters) is often an indication of a Leaky Abstraction. It indicates that the consumer has knowledge about the dependency's lifetime that it shouldn't have.

We can remove this flaw by introducing a Decorator of the IRepository<T> interface. Something like this should suffice:

public class FoundRepository<T> : IRepository<T>
{
    private readonly IRepository<T> repository;
 
    public FoundRepository(IRepositoryFinder<T> finder)
    {
        if (finder == null)
        {
            throw new ArgumentNullException("finder");
        }
 
        this.repository = finder.FindRepository();
    }
 
    /* Implement IRepository<T> by delegating to
     * this.repository */
}

This means that we can change the implementation of MyServiceOperation to this:

public void MyServiceOperation(
    IRepository<Customer> repository)
{
    // ...
}

This is much better, but this requires a couple of notes.

First of all we should keep in mind that since FoundRepository creates and saves an instance of IRepository right away, we should control the lifetime of FoundRepository. In essense, the lifetime should be tied to the specific service operation. Two concurrent invocations of MyServiceOperation should each receive separate instances of FoundRepository.

Many DI containers support Factory methods, so it may not even be necessary to implement FoundRepository explicitly. Rather, it would be possible to register IRepository<T> so that an instance is always created by invoking IRepositoryFinder<T>.FindRepository().

Comments

One of the readers of my book recently asked me an interesting question that relates to the disadvantages of the Service Locator anti-pattern. I found both the question and the potential solution so interesting that I would like to share it.

In short, the reader's organization currently uses Service Locator in their code, but don't really see a way out of it. This post demonstrates how we can refactor from Service Locator to Abstract Factory. Here's the original question:

"We have been writing a WCF middle tier using DI

"Our application talks to multiple databases.  There is one Global database which contains Enterprise records, and each Enterprise has the connection string of a corresponding Enterprise database.

"The trick is when we want to write a service which connects to an Enterprise database.  The context for which enterprise we are dealing with is not available until one of the service methods is called, so what we do is this:

public void MyServiceOperation(
    EnterpriseContext context)
{
    /* Get a Customer repository operating
        * in the given enterprise's context
        * (database) */
    var customerRepository = 
        context.FindRepository<Customer>(
            context.EnterpriseId);
    // ...
}

"I'm not sure how, in this case, we can turn what we've got into a more pure DI system, since we have the dependency on the EnterpriseContext passed in to each service method.  We are mocking and testing just fine, and seem reasonably well decoupled.  Any ideas?"

When we look at the FindRepository method we quickly find that it's a Service Locator. There are many problems with Service Locator, but the general issue is that the generic argument can be one of an unbounded set of types.

The problem is that seen from the outside, the consuming type (MyService in the example) doesn't advertise its dependencies. In the example the dependency is a CustomerRepository, but you could later go into the implementation of MyServiceOperation and change the call to context.FindRepository<Qux>(context.EnterpriseId) and everything would still compile. However, at run-time, you'd likely get an exception.

It would be much safer to use an Abstract Factory, but how do we get there from here, and will it be better?

Let's see how we can do that. First, we'll have to make some assumptions on how EnterpriseContext works. In the following, I'll assume that it looks like this - warning: it's ugly, but that's the point, so don't give up reading just yet:

public class EnterpriseContext
{
    private readonly int enterpriseId;
    private readonly IDictionary<int, string> 
        connectionStrings;
 
    public EnterpriseContext(int enterpriseId)
    {
        this.enterpriseId = enterpriseId;
 
        this.connectionStrings =
            new Dictionary<int, string>();
        this.connectionStrings[1] = "Foo";
        this.connectionStrings[2] = "Bar";
        this.connectionStrings[3] = "Baz";
    }
 
    public virtual int EnterpriseId
    {
        get { return this.enterpriseId; }
    }
 
    public virtual IRepository<T> FindRepository<T>(
        int enterpriseId)
    {
        if (typeof(T) == typeof(Customer))
        {
            return (IRepository<T>)this
                .FindCustomerRepository(enterpriseId);
        }
        if (typeof(T) == typeof(Campaign))
        {
            return (IRepository<T>)this
                .FindCampaignRepository(enterpriseId);
        }
        if (typeof(T) == typeof(Product))
        {
            return (IRepository<T>)this
                .FindProductRepository(enterpriseId);
        }
 
        throw new InvalidOperationException("...");
    }
 
    private IRepository<Campaign>
        FindCampaignRepository(int enterpriseId)
    {
        var cs = this.connectionStrings[enterpriseId];
        return new CampaignRepository(cs);
    }
 
    private IRepository<Customer>
        FindCustomerRepository(int enterpriseId)
    {
        var cs = this.connectionStrings[enterpriseId];
        return new CustomerRepository(cs);
    }
 
    private IRepository<Product>
        FindProductRepository(int enterpriseId)
    {
        var cs = this.connectionStrings[enterpriseId];
        return new ProductRepository(cs);
    }
}

That's pretty horrible, but that's exactly the point. Every time we need to add a new type of repository, we'll need to modify this class, so it's one big violation of the Open/Closed Principle.

I didn't implement EnterpriseContext with a DI Container on purpose. Yes: using a DI Container would make it appear less ugly, but it would only hide the design issue - not address it. I chose the above implementation to demonstrate just how ugly this sort of design really is.

So, let's start refactoring.

Step 1 #

We change each of the private finder methods to public methods.

In this example, there are only three methods, but I realize that in a real system there might be many more. However, we'll end up with only a single interface and its implementation, so don't despair just yet. It'll turn out just fine.

As a single example the FindCustomerRepository method is shown here:

public IRepository<Customer>
    FindCustomerRepository(int enterpriseId)
{
    var cs = this.connectionStrings[enterpriseId];
    return new CustomerRepository(cs);
}

For each of the methods we extract an interface, like this:

public interface ICustomerRepositoryFinder
{
    int EnterpriseId { get; }
 
    IRepository<Customer> FindCustomerRepository(
        int enterpriseId);
}

We also include the EnterpriseId property because we'll need it soon. This is just an intermediary artifact which is not going to survive until the end.

This is very reminiscent of the steps described by Udi Dahan in his excellent talk Intentions & Interfaces: Making patterns concrete. We make the roles of finding repositories explicit.

This leaves us with three distinct interfaces that EnterpriseContext can implement:

public class EnterpriseContext : 
    ICampaignRepositoryFinder,
    ICustomerRepositoryFinder,
    IProductRepositoryFinder

Until now, we haven't touched the service.

Step 2 #

We can now change the implementation of MyServiceOperation to explicitly require only the role that it needs:

public void MyServiceOperation(
    ICustomerRepositoryFinder finder)
{
    var customerRepository = 
        finder.FindCustomerRepository(
            finder.EnterpriseId);
}

Since we now only consume the strongly typed role interfaces, we can now delete the original FindRepository<T> method from EnterpriseContext.

Step 3 #

At this point, we're actually already done, since ICustomerRepositoryFinder is an Abstract Factory, but we can make the API even better. When we consider the implementation of MyServiceOperation, it should quickly become clear that there's a sort of local Feature Envy in play. Why do we need to access finder.EnterpriseId to invoke finder.FindCustomerRepository? Shouldn't it rather be the finder's own responsibility to figure that out for us?

Instead, let us change the implementation so that the method does not need the enterpriseId parameter:

public IRepository<Customer> FindCustomerRepository()
{
    var cs = 
        this.connectionStrings[this.EnterpriseId];
    return new CustomerRepository(cs);
}

Notice that the EnterpriseId can be accessed just as well from the implementation of the method itself. This change requires us to also change the interface:

public interface ICustomerRepositoryFinder
{
    IRepository<Customer> FindCustomerRepository();
}

Notice that we removed the EnterpriseId property, as well as the enterpriseId parameter. The fact that there's an enterprise ID in play is now an implementation detail.

MyServiceOperation now looks like this:

public void MyServiceOperation(
    ICustomerRepositoryFinder finder)
{
    var customerRepository = 
        finder.FindCustomerRepository();
}

This takes care of the Feature Envy smell, but still leaves us with a lot of very similarly looking interfaces: ICampaignRepositoryFinder, ICustomerRepositoryFinder and IProductRepositoryFinder.

Step 4 #

We can collapse all the very similar interfaces into a single generic interface:

public interface IRepositoryFinder<T>
{
    IRepository<T> FindRepository();
}

With that, MyServiceOperation now becomes:

public void MyServiceOperation(
    IRepositoryFinder<Customer> finder)
{
    var customerRepository = 
        finder.FindRepository();
}

Now that we only have a single generic interface (which is still an Abstract Factory), we can seriously consider getting rid of all the very similarly looking implementations in EnterpriseContext and instead just create a single generic class. We now have a more explicit API that better communicates intent.

How is this better? What if a method needs both an IRepository<Customer> and an IRepository<Product>? We'll now have to pass two parameters instead of one.

Yes, but that's good because it explicitly calls to your attention exactly which collaborators are involved. With the original Service Locator, you might not notice the responsibility creep as you over time request more and more repositories from the EnterpriseContext. With Abstract Factories in play, violations of the Single Responsibility Principle (SRP) becomes much more obvious.

Refactoring from Service Locator to Abstract Factories make it more painful to violate the SRP.

You can always make roles explicit to get rid of Service Locators. This is likely to result in a more explicit design where doing the right thing feels more natural than doing the wrong thing.

It's easy to confuse the Abstract Factory pattern with the Service Locator anti-pattern - particularly so when generics or contextual information is involved. However, it's really easy to distinguish between there two, and here's how!

Here are both (anti-)patterns in condensed form opposite each other:

public interface IFactory<T>
{
    T Create(object context);
}

public interface IServiceLocator
{
    T Create<T>(object context);
}

For these examples I chose to demonstrate both as generic interfaces that take some kind of contextual information (context) as input.

In this example the context can be any object, but we could also have considered a more strongly typed context parameter. Other variations include more than one method parameter, or, in the degenerate case, no parameters at all.

Both interfaces have a simple Create method that returns the generic type T, so it's easy to confuse the two. However, even for generic types, it's easy to tell one from the other:

An Abstract Factory is a generic type, and the return type of the Create method is determined by the type of the factory itself. In other words, a constructed type can only return instances of a single type.

A Service Locator, on the other hand, is a non-generic interface with a generic method. The Create method of a single Service Locator can return instances of an infinite number of types.

Even simpler:

An Abstract Factory is a generic type with a non-generic Create method; a Service Locator is a non-generic type with a generic Create method.

The name of the method, the number of parameters, and other circumstances may vary. The types may not be generic, or may be base classes instead of interfaces, but at the heart of it, the question is whether you can ask for an arbitrary type from the service, or only a single, static type.

Comments

As previous posts have described, AutoFixture creates Anonymous Variables based on the notion of being able to always hit within a well-behaved Equivalence Class for a given type. This works well a lot of the time because AutoFixture has some sensible defaults: numbers are positive integers and strings are GUIDs.

This last part only works as long as strings are nothing but opaque blobs to the consuming class. This is, however, not an unreasonable assumption. Consider classes that implement Entities such as Person or Address. Strings will often take the form of FirstName, LastName, Street, etc. In all such cases, the value of the string usually doesn't matter.

However, there will always be cases where the value of a string has a special meaning of its own. It will often be best to let AutoFixture guide us towards a better API design, but this is not always possible. Sometimes there are rules that constrain the formatting of a string.

As an example, consider a Money class with this constructor:

public Money(decimal amount, string currencyCode)
{
    if (currencyCode == null)
    {
        throw new ArgumentNullException("...");
    }
    if (!CurrencyCodes.IsValid(currencyCode))
    {
        throw new ArgumentException("...");
    }
 
    this.amount = amount;
    this.currencyCode = currencyCode;
}

Notice that the constructor only allows properly formatted currency codes (such as e.g. “DKK”, “USD”, “AUD”, etc.) through, while other strings will throw an exception. AutoFixture's default behavior of creating GUIDs as strings is problematic, as the Money constructor will throw on a GUID.

We could attempt to fix this by changing the way AutoFixture generates strings in general, but that may not be the best solution as it may interfere with other string values. It is, however, easy to do:

fixture.Inject("DKK");

This simply injects the “DKK” string into the fixture, causing all subsequent strings to have the same value. However, a hypothetical Pizza class with Name and Description properties in addition to a Price property of type Money will now look like this:

{
  "Name": "DKK",
  "Price": {
    "Amount": 1.0,
    "CurrencyCode": "DKK"
  },
  "Description": "DKK"
}

What we really want is to customize only the currency code. This is where the extremely customizable architecture of AutoFixture can help us. As the documentation explains, lots of different request will flow through the kernel's Chain of Responsibility to create a Money instance. To populate the two parameters of the Money constructor, two ParameterInfo requests will be issued - one for each parameter. We can take advantage of this to create a custom ISpecimenBuilder that only addresses string parameters with the name currencyCode.

public class CurrencyCodeSpecimenBuilder : 
    ISpecimenBuilder
{
    public object Create(object request,
        ISpecimenContext context)
    {
        var pi = request as ParameterInfo;
        if (pi == null)
        {
            return new NoSpecimen(request);
        }
        if (pi.ParameterType != typeof(string)
            || pi.Name != "currencyCode")
        {
            return new NoSpecimen(request);
        }
 
        return "DKK";
    }
}

It simply examines the request to determine whether this is something that it should address at all. Only if the request is a ParameterInfo representing a string parameter named currencyCode do we deal with it. In any other case we return NoSpecimen, which simply tells AutoFixture that it should ask another ISpecimenBuilder instead.

Here we just return the hard-coded string “DKK”, but we could easily have expanded the example to use a more varied generation algorithm. I will leave that, as well as how to generalize this in other ways, as exercises to the reader.

With CurrencyCodeSpecimenBuilder available, we can add it to the Fixture like this:

fixture.Customizations.Add(
    new CurrencyCodeSpecimenBuilder());

With this customization added, a Pizza instance now looks like this:

{
  "Name": "namec6b7a923-ea78-4817-9e24-a6863a597645",
  "Price": {
    "Amount": 1.0,
    "CurrencyCode": "DKK"
  },
  "Description": "Description63ef17d7-876d-46d8-af73-1ed91f83e699"
}

Notice how only the currency code is affected while all other string values are created by the default algorithm.

In a nutshell, a custom ISpecimenBuilder can be used to implement all sorts of custom conventions for AutoFixture. The one shown here applies the string “DKK” to all string parameters named currencyCode. This mean that the convention isn't necessarily constrained to the Money constructor, but applies to all ParamterInfo instances that fit the specification.

Comments

Recently I attended a workshop where we attempted to migrate an existing web application to Windows Azure. It was a worthwhile workshop that left me with a few key takeaways related to migrating applications to Windows Azure.

The first and most important point is so self-evident that I seriously considered not publishing it. However, apparently it wasn't self-evident to all workshop participants, so someone else might also benefit from this general advice:

Before migrating to Windows Azure, make sure that the application scales to at least two normal servers.

It's as simple as that - still, lots of web developers never consider this aspect of application architecture.

Why is this important in relation to Azure? The Windows Azure SLA only applies if you deploy two or more instances, which makes sense since the hosting servers occasionally need to be patched etc.

Unless you don't care about the SLA, your application must be able to ‘scale' to at least two servers. If it can't, fix this issue first, before attempting to migrate to Windows Azure. You can test this locally by simply installing your application on two different servers and put them behind a load balancer (you can use virtual machines if you don't have the hardware). Only if it works consistently in this configuration should you consider deploying to Azure.

Here are the most common issues that may prevent the application from ‘scaling':

• Keeping state in memory. If you must use session state, use one of the out-of-process session state store providers.
• Using the file system for persistent storage. The file system is local to each server.

Making sure that the application ‘scales' to at least two servers is such a simple sanity check that it should go without saying, but apparently it doesn't.

Please note that I put ‘scaling' in quotes here. An application that runs on only two servers has yet to prove that it's truly scalable, but that's another story.

Also note that this sanity check in no way guarantees that the application will run on Azure. However, if the check fails, it most likely will not.

Comments

It gives me great pleasure to announce the release of AutoFixture 2.0. This release fixes a few minor issues since beta 1, but apart from that there are no significant changes.

This is a major release compared to AutoFixture 1.1, featuring a completely new kernel, as well as new features and extensibility points. The beta 1 announcement sums up the changes. Get it here.

AutoFixture 2.0 comes with a new extension for xUnit.net data theories. For those of us using xUnit.net, it can help make our unit tests more succinct and declarative.

AutoFixture's support for xUnit.net is implemented in a separate assembly. AutoFixture itself has no dependency on xUnit.net, and if you use another unit testing framework, you can just ignore the existence of the Ploeh.AutoFixture.Xunit assembly.

Let's go back and revisit the previous test we wrote using AutoFixture and its auto-mocking extension:

[Fact]
public void AddWillPipeMapCorrectly()
{
    // Fixture setup
    var fixture = new Fixture()
        .Customize(new AutoMoqCustomization());
 
    var basket = fixture.Freeze<Basket>();
    var mapMock = fixture.Freeze<Mock<IPizzaMap>>();
 
    var pizza = fixture.CreateAnonymous<PizzaPresenter>();
 
    var sut = fixture.CreateAnonymous<BasketPresenter>();
    // Exercise system
    sut.Add(pizza);
    // Verify outcome
    mapMock.Verify(m => m.Pipe(pizza, basket.Add));
    // Teardown
}

Notice how all of the Fixture Setup phase is only used to create various objects that will be used in the test. First we create the fixture object, and then we use it to create four other objects. That turns out to be a pretty common idiom when using AutoFixture, so it's worthwhile to reduce the clutter if possible.

With xUnit.net's excellent extensibility features, we can. AutoFixture 2.0 now includes the AutoDataAttribute in a separate assembly. AutoDataAttribute derives from xUnit.net's DataAttribute (just like InlineDataAttribute), and while we can use it as is, it becomes really powerful if we combine it with auto-mocking like this:

public class AutoMoqDataAttribute : AutoDataAttribute
{
    public AutoMoqDataAttribute()
        : base(new Fixture()
            .Customize(new AutoMoqCustomization()))
    {
    }
}

This is a custom attribute that combines AutoFixture's two optional extensions for auto-mocking and xUnit.net support. With the AutoMoqDataAttribute in place, we can now rewrite the above test like this:

[Theory, AutoMoqData]
public void AddWillPipeMapCorrectly([Frozen]Basket basket,
    [Frozen]Mock<IPizzaMap> mapMock, PizzaPresenter pizza,
    BasketPresenter sut)
{
    // Fixture setup
    // Exercise system
    sut.Add(pizza);
    // Verify outcome
    mapMock.Verify(m => m.Pipe(pizza, basket.Add));
    // Teardown
}

The AutoDataAttribute simply uses a Fixture object to create the objects declared in the unit tests parameter list. Notice that the test is no longer a [Fact], but rather a [Theory].

The only slightly tricky thing to notice is that when we declare a parameter object, it will automatically map to a call to the CreateAnonymous method for the parameter type. However, when we need to invoke the Freeze method, we can add the [Frozen] attribute in front of the parameter.

The best part about data theories is that they don't prevent us from writing normal unit tests in the same Test Class, and this carries over to the [AutoData] attribute. We can use it when it's possible, but for those more complex tests where we need to interact with a Fixture instance, we can still write a normal [Fact].

Comments