Testability Is Really The Open/Closed Principle

Friday, 05 June 2009 07:56:19 UTC

When I talk with people about TDD and unit testing, the discussion often moves into the area of Testability - that is, the software's susceptibility to unit testing. A couple of years back, Roy even discussed the seemingly opposable forces of Object-Oriented Design and Testability.

Lately, it has been occurring to me that there really isn't any conflict. Encapsulation is important because it manifests expert knowledge so that other developers can effectively leverage that knowledge, and it does so in a way that minimizes misuse.

However, too much encapsulation goes against the Open/Closed Principle (that states that objects should be open for extension, but closed for modification). From a Testability perspective, the Open/Closed Principle pulls object-oriented design in the desired direction. Equivalently, done correctly, making your API Testable is simply opening it up for extensibility.

As an example, consider a simple WPF ViewModel class called MainWindowViewModel. This class has an ICommand property that, when invoked, should show a message box. Showing a message box is good example of breaking testability, because if the SUT were to show a message box, it would be very hard to automatically verify and we wouldn't have fully automated tests.

For this reason, we need to introduce an abstraction that basically models an action with a string as input. Although we could define an interface for that, an Action<string> fits the bill perfectly.

To enable that feature, I decide to use Constructor Injection to inject that abstraction into the MainWindowViewModel class:

public MainWindowViewModel(Action<string> notify)
    this.ButtonCommand = new RelayCommand(p => 
    { notify("Button was clicked!"); });

When I recently did that at a public talk I gave, one member of the audience initially reacted by assuming that I was now introducing test-specific code into my SUT, but that's not the case.

What I'm really doing here is opening the MainWindowViewModel class for extensibility. It can still be used with message boxes:

var vm = new MainWindowViewModel(s => MessageBox.Show(s));

but now we also have the option of notifying by sending off an email; writing to a database; or whatever else we can think of.

It just so happens that one of the things we can do instead of showing a message box, is unit testing by passing in a Test Double.

// Fixture setup
var mockNotify = 
mockNotify.Expect(a => a("Button was clicked!"));
var sut = new MainWindowViewModel(mockNotify);
// Exercise system
sut.ButtonCommand.Execute(new object());
// Verify outcome
// Teardown

Once again, TDD has lead to better design. In this case it prompted me to open the class for extensibility. There really isn't a need for Testability as a specific concept; the Open/Closed Principle should be enough to drive us in the right direction.

Pragmatically, that's not the case, so we use TDD to drive us towards the Open/Closed Principle, but I think it's important to note that we are not only doing this to enable testing: We are creating a better and more flexible API at the same time.

AutoFixture Cheat Sheet

Thursday, 04 June 2009 21:15:08 UTC

To make it a bit easier to get started with AutoFixture without having to trawl through all my blog posts, I've added a Cheat Sheet over at the AutoFixture CodePlex site.

As I add more posts on AutoFixture, I'll update the Cheat Sheet with the essentials. Please let me know if you think something's missing.

Setting Property Values While Building Anonymous Variables With AutoFixture

Monday, 01 June 2009 12:35:18 UTC

In my previous post I described how the Build method can be used to customize how a single anonymous variable is created.

A common customization is to set a property value during creation. In most cases, this can simply be done after the anonymous variable has been created (so the following is not an AutoFixture customization):

var mc = fixture.CreateAnonymous<MyClass>();
mc.MyText = "Ploeh";

By default, AutoFixture assigns anonymous values to all writable properties, but since they are writable, you can always explicitly give them different values if you care.

However, there are situations when a property is writable, but can't take just any value of its type. Sometimes this is a sign that you should reconsider your API, as I've previously described, but it may also be a legitimate situation.

Consider a Filter class that has Min and Max properties. To be semantically correct, the Min property must be less than or equal to the Max property. Each property is implemented like this:

public int Min
    get { return this.min; }
        if (value > this.Max)
            throw new ArgumentOutOfRangeException("value");
        this.min = value;

When you ask AutoFixture to create an instance of the Filter class, it will throw an exception because it's attempting to set the Min property after the Max property, and the default algorithm for numbers is to return numbers in an increasing sequence. (In this example, the Min property is being assigned a value after the Max property, but AutoFixture has no contract that states that the order in which properties are assigned is guaranteed.) In other words, this throws an exception:

var f = fixture.CreateAnonymous<Filter>();

To solve this problem, we will have to customize the assignment of the Min and Max properties, before we ask AutoFixture to create an instance of the Filter class. Here's how to do that:

int min = fixture.CreateAnonymous<int>();
int max = min + 1;
var f = fixture.Build<Filter>()
    .With(s => s.Max, max)
    .With(s => s.Min, min)

The With method lets you specify an expression that identifies a property, as well as the value that should be assigned to that property. When you do that, AutoFixture will never attempt to assign an anonymous value to that property, but will instead use the value you specified.

In most cases, just creating a truly anonymous instance and subsequently explicitly assigning any significant values is easier, but using the Build method with one or more calls to the With method gives you the power to override any property assignments before the instance is created.

Delegates Are Anonymous Interfaces

Thursday, 28 May 2009 20:19:04 UTC

This is really nothing new, but I don't think I've explicitly stated this before: It makes a lot of sense to view delegates as anonymous one-method interfaces.

Many people liken delegates to function pointers. While that's probably correct (I wouldn't really know), it's not a very object-oriented view to take - at least not when we are dealing with managed code. To me, it makes more sense to view delegates as anonymous one-method interfaces.

Lets consider a simple example. As always, we have the ubiquitous MyClass with its DoStuff method. In this example, DoStuff takes as input an abstraction that takes a string as input and returns an integer - let's imagine that this is some kind of Strategy (notice the capital S - I'm talking about the design pattern, here).

In traditional object-oriented design, we could solve this by introducing the IMyInterface type:

public interface IMyInterface
    int DoIt(string message);

The implementation of DoStuff is simply:

public string DoStuff(IMyInterface strategy)
    return strategy.DoIt("Ploeh").ToString();

Hardly rocket science…

However, defining a completely new interface just to do this is not really necessary, since we could just as well have implemented DoStuff with a Func<string, int>:

public string DoStuff(Func<string, int> strategy)
    return strategy("Ploeh").ToString();

This not only frees us from defining a new interface, but also from implementing that interface to use the DoStuff method. Instead, we can simply pass a lambda expression:

string result = sut.DoStuff(s => s.Count());

What's most amazing is that RhinoMocks understands and treats delegates just like other abstract types, so that we can write the following to treat it as a mock:

// Fixture setup
Func<string, int> mock =
    MockRepository.GenerateMock<Func<string, int>>();
mock.Expect(f => f("Ploeh")).Return(42);
var sut = new MyClass();
// Exercise system
string result = sut.DoStuff(mock);
// Verify outcome
// Teardown

Whenever possible, I prefer to model my APIs with delegates instead of one-method interfaces, since it gives me greater flexibility and less infrastructure code.

Obviously, this technique only works as long as you only need to abstract a single method. As soon as your abstraction needs a second method, you will need to introduce a proper interface or, preferably, an abstract base class.


jonnie savell
"While that's probably correct (I wouldn't really know), it's not a very object-oriented view to take."

We shouldn't believe that delegates are unlike a function pointer just because the latter is not object-oriented. The shoe ... fits. Furthermore, I would argue that an anonymous one-method interfaces is not a first-class object-oriented concept; we can describe it with words, but I doubt that you will find any of the non-.NET literature talking about such a thing. Well ... I will grant that mention might be made under a description of the command pattern.

"Obviously, this technique only works as long as you only need to abstract a single method."

Yes. Then we are in trouble and we didn't even swim that far from shore.

What was the problem? We focussed too much on a method and we ignored the interface. An interface defines the contract of which the method is only a part. The contract is identified by the name of the interface. There is no contract defined by method signatures. "Takes an int and a double and returns a string" doesn't mean anything.

In summary, focussing on the method is every bit as dirty as ... function pointers.

jonnie savell
2010-04-07 07:47 UTC

The AutoFixture Builder

Tuesday, 26 May 2009 21:30:35 UTC

Until now, I've shown you how you can make wholesale adjustments or customizations to an entire Fixture instance, effectively changing the way it creates all instances of a particular type.

In some scenarios, you'd rather want to customize how a single instance is created without influencing other instances of the same type. For this purpose, AutoFixture includes a class called ObjectBuilder<T> that can be used to do exactly that.

The easiest way to get an instance of this class is by calling Build on a Fixture instance. This will give you an instance of ObjectBuilder<T> that you can use to customize the build steps. When you are done, CreateAnonymous returns the built instance.

var mc = fixture.Build<MyClass>().CreateAnonymous();

This particular example doesn't define any customizations, so it's equivalent to

var mc = fixture.CreateAnonymous<MyClass>();

In fact, Fixture.CreateAnonymous is little more than a convenience method wrapping an ObjectBuilder (there's a few extra differences, but that's a topic for another post).

It's worth noting that the object specified by the type parameter to the Build method is first created when you call CreateAnonymous.

In future posts I'll demonstrate how to use the Build method to customize individual anonymous variables.

SyncOrchestrator.Synchronize() Throws COMException When Unit Testing

Thursday, 21 May 2009 18:54:01 UTC

This post describes a particular problem I ran into when working with the Microsoft Sync Framework. Since I found a solution, I'm sharing it here to help others. If you are not having this particular problem, it's quite safe to skip reading the rest of the post :)

While developing a SyncProvider, I wanted to create and execute a series of Integration Tests to drive my development effort. In order to do that, I wrote a simple test that simply created a SyncOrchestrator instance and invoked its Synchronize method.

Running this test gave me this error message:

“Microsoft.Synchronization.SyncException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154. --->  System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {A7B3B4EE-925C-4D6C-B007-A4A6A0B09143} failed due to the following error: 80040154.”

It's not often I see a COMException these days, so I was initially baffled. Since the Sync Framework also has an unmanaged API, this is really not surprising, but that didn't help me solve my problem.

What was even weirder was that when I tried running the same code in my application, this exception was not being thrown.

It took me a couple of hours to figure out what the problem was.

Here's a little hint: I'm running Windows Vista x64.

No: The issue is not that I'm running Vista :)

Even on x64, Visual Studio runs as a 32-bit process, and so does MSTest. Since my code was compiled to Any CPU, the application itself was running in a 64-bit process, whereas my unit test was running in a 32-bit process.

I tried changing my build output to x86, and now the application started throwing the same exception as the unit test did.

In other words: When running in a 64-bit process, everything worked as intended. When running in a 32-bit process, a COMException was thrown.

As it turned out, I had only installed the 64-bit version of the Sync Framework, and even though the SDK seems to contain builds for the other architectures as well, the COM Server wasn't properly registered for 32-bit use.

To resolve this issue, I downloaded and installed the x86 version of the Sync Framework as well, and the problem went away.

If you are having the same problem, I hope this post helps you resolve it.


Reginald Henderson
PERFECT. This is exactly what I needed!!! Thanks dude.
2009-07-10 12:46 UTC
Hi Reginal

Thank you for your message - I am happy that my post was helpful to you.
2009-07-10 19:23 UTC
Thanks for this, I stumbled on this one today. My issue was simply that it was still compiling for "Any CPU". I simply changed it to x86, and there were no problems.
2010-03-07 02:45 UTC
Thanks, that did the job!
2011-09-09 07:49 UTC
Michael N
Thank you for the information; this worked for me!

I was trying to find out why SharePoint Workspace did not work on my workstation. It was failing with the "Class not found" 80040154 error, and I found your article with a Google search on the CLSID. Installing Microsoft Sync Framework 1.0 SP1 fixed the problem, and I would never have known where to look without your article.
2011-09-14 11:25 UTC

AutoFixture .8.1 Released

Sunday, 17 May 2009 07:48:36 UTC

Today I've created a new release (.8.1 for lack of a better version number) of AutoFixture. While it contains some breaking changes, they all relate to features that I have yet to cover here on the blog - in other words: All the examples that I've posted so far are still valid.

AutoFixture As Fixture Object

Friday, 15 May 2009 05:34:00 UTC

Dear reader, I hope you are still with me!

After eight posts of AutoFixture feature walkthroughs, I can't blame you for wondering why this tool might even be relevant to you. In this post, we'll finally begin to look at how AutoFixture can help you towards Zero-Friction TDD!

In an earlier post, I described how the Fixture Object pattern can help you greatly reduce the amount of test code that you have to write. Since AutoFixture was designed to act as a general-purpose Fixture Object, it can help you reduce the amount of test code even further, letting you focus on specifying the behavior of your SUT.

In that former post, the original example was this complex test that I will repeat in it's entirety for your benefit (or horror):

public void NumberSumIsCorrect_Naïve()
    // Fixture setup
    Thing thing1 = new Thing()
        Number = 3,
        Text = "Anonymous text 1"
    Thing thing2 = new Thing()
        Number = 6,
        Text = "Anonymous text 2"
    Thing thing3 = new Thing()
        Number = 1,
        Text = "Anonymous text 3"
    int expectedSum = new[] { thing1, thing2, thing3 }.
        Select(t => t.Number).Sum();
    IMyInterface fake = new FakeMyInterface();
    MyClass sut = new MyClass(fake);
    // Exercise system
    int result = sut.CalculateSumOfThings();
    // Verify outcome
    Assert.AreEqual<int>(expectedSum, result,
        "Sum of things");
    // Teardown

This test consists of 18 lines of code.

Using the Fixture Object pattern, I was able to cut that down to 7 lines of code, which is a 61% improvement (however, the downside was an additional 19 lines of (reusable) code for MyClassFixture, so the benefit can only be reaped when you have multiple tests leveraged by the same Fixture Object. This was all covered in the former post, to which I will refer you).

With AutoFixture, we can do much better. Here's a one-off rewrite of the unit test using AutoFixture:

public void NumberSumIsCorrect_AutoFixture()
    // Fixture setup
    Fixture fixture = new Fixture();
    IMyInterface fake = new FakeMyInterface();
    fixture.Register<IMyInterface>(() => fake);
    var things = fixture.CreateMany<Thing>().ToList();
    things.ForEach(t => fake.AddThing(t));
    int expectedSum = things.Select(t => t.Number).Sum();
    MyClass sut = fixture.CreateAnonymous<MyClass>();
    // Exercise system
    int result = sut.CalculateSumOfThings();
    // Verify outcome
    Assert.AreEqual<int>(expectedSum, result,
        "Sum of things");
    // Teardown

In this test, I map the concrete fake instance to the IMyInterface type in the fixture object, and then use its ability to create many anonymous instances with one method call. Before exercising the SUT, I also use the fixture instance as a SUT Factory.

Apart from AutoFixture (and FakeMyInterface, which is invariant for all variations, and thus kept out of the comparison), this test stands alone, but still manages to reduce the number of code lines to 10 lines - a 44% improvement! In my book, that's already a significant gain in productivity and maintainability, but we can do better!

If we need to test MyClass repeatedly in similar ways, we can move the common code to a Fixture Object based on AutoFixture, and the test can be refactored to this:

public void NumberSumIsCorrect_DerivedFixture()
    // Fixture setup
    MyClassFixture fixture = new MyClassFixture();
    int expectedSum = 
        fixture.Things.Select(t => t.Number).Sum();
    MyClass sut = fixture.CreateAnonymous<MyClass>();
    // Exercise system
    int result = sut.CalculateSumOfThings();
    // Verify outcome
    Assert.AreEqual<int>(expectedSum, result,
        "Sum of things");
    // Teardown

Now we are back at 7 lines of code, which is on par with the original Fixture Object-based test, but now MyClassFixture is reduced to 8 lines of code:

internal class MyClassFixture : Fixture
    internal MyClassFixture()
        this.Things = new List<Thing>();
        this.Register<IMyInterface>(() =>
                var fake = new FakeMyInterface();
                this.Things.ToList().ForEach(t =>
                return fake;
    internal IList<Thing> Things { get; private set; }

Notice how I've moved the IMyInterface-to-FakeMyInterface mapping to MyClassFixture. Whenever it's asked to create a new instance of IMyInterface, MyClassFixture makes sure to add all the Thing instances to the fake before returning it.

Compared to the former Fixture Object of 19 lines, that's another 58% improvement. Considering some of the APIs I encounter in my daily work, the above example is even rather simple. The more complex and demanding your SUT's API is, the greater the gain from using AutoFixture will be, since it's going to figure out much of the routine stuff for you.

With this post, I hope I have given you a taste of the power that AutoFixture provides. It allows you to focus on specifying the behavior of your SUT, while taking care of all the infrastructure tedium that tends to get in the way.

Anonymous Sequences With AutoFixture

Monday, 11 May 2009 20:25:42 UTC

When writing unit tests you often need to deal with sequences and collections, populating lists with anonymous data as part of setting up a Fixture.

This is easy to do with AutoFixture. While you can obviously create a simple loop and call CreateAnonymous from within the loop, AutoFixture provides some convenient methods for working with sequences.

Equivalent to the CreateAnonymous method, the Fixture class also includes the CreateMany method that creates a sequence of anonymous variables. CreateManyAnonymous might have been a more concise and consistent name for the method, but I felt that this was a bit too verbose.

This will create an IEnumerable<string>:

Fixture fixture = new Fixture();
var strings = fixture.CreateMany<string>();

Obviously, you can create sequences of whatever type you want, as long as AutoFixture can figure out how to create instances of the type:

var myInstances = fixture.CreateMany<MyClass>();

Being able to create sequences of anonymous data is nice, but sometimes you need to add multiple anonymous items to an existing list (particularly if that list is a read-only property of your SUT).

To support that scenario, the Fixture class also has the AddManyTo method that can be used like this:

var list = new List<MyClass>();

This simply creates many anonymous MyClass instances and adds them all to the list. Once more, AddManyAnonymousTo might have been a more precise name, but again I chose a less verbose alternative.

If you want more control over how the instances are created, a more explicit overload of AddManyTo gives you that.

var list = new List<int>();
var r = new Random();
fixture.AddManyTo(list, () => r.Next());

The above examples adds many random numbers to the list of integers, since the second parameters is a Func<T> used to create the instances.

By default, these methods all create 3 anonymous variables when called, since 3 is a good equivalent for many. If you want a different number of instances to be created, you can modify the RepeatCount property.

fixture.RepeatCount = 10;
var sequence = fixture.CreateMany<MyClass>();

The above example will create an IEnumerable<MyClass> with 10 anonymous MyClass instances, while this will add 7 anonymous instances to the list variable:

var list = new List<MyClass>();
fixture.RepeatCount = 7;

AutoFixture provides some convenient methods for creating and managing collections of anonymous data. While it may seem simple (and it is), in a future post I will demonstrate how it can save you quit a bit of infrastructure code, and enable you to write unit tests that are shorter, more concise and more maintainable.

Managing Loosely Coupled Projects

Tuesday, 05 May 2009 18:54:11 UTC

Udi recently posted an article on managing loose coupling in Visual Studio. While I completely agree, this is a topic that deserves more detailed treatment. In particular, I'd like to expand on this statement:

"In fact, each component could theoretically have its own solution"

This is really the crux of the matter, although in practical terms, you'd typically need at least a couple of projects per component. In special cases, a component may truly be a stand-alone component, requiring no other dependencies than what is already in the BCL (in fact, AutoFixture is just such a component), but most components of more complex software have dependencies.

Even when you are programming against interfaces (which you should be), these interfaces will normally be defined in other projects.


A component may even use multiple interfaces, since it may be implementing some, but consuming others, and these interfaces may be defined in different projects. This is particularly the case with Adapters.

Finally, you should have at least one unit test project that targets your component.

In essence, while the exact number of projects you need will vary, it should stay small. In the figure above, we end up with five projects, but there's also quite a few abstractions being pulled in.

As a rule of thumb I'd say that if you can't create an .sln file that contains less than ten projects to work on any component, you should seriously consider your decoupling strategy.

You may choose to work with more than ten projects in a solution, but it should always be possible to create a solution to work with a single component, and it should drag only few dependencies along.

Page 61 of 63

"Our team wholeheartedly endorses Mark. His expert service provides tremendous value."
Hire me!