Anonymous Do

Thursday, 26 November 2009 21:23:46 UTC

In unit testing an important step is to exercise the SUT. The member you want to invoke is often a method that takes one or more parameters, but in some test cases you don't care about the values of those parameters - you just want to invoke the method.

You can always make up one or more Dummy parameters and pass them to the method in question, but you could also use one of AutoFixture's Do convenience methods. There are several overloads that all take delegates that specify the action in question while providing you with Dummies of any parameters you don't care about.

A good example is WPF's ICommand interface. The most prevalent method is the Execute method that takes a single parameter parameter:

void Execute(object parameter);

Most of the time we don't really care about the parameter because we only care that the command was invoked. However, we still need to supply a value for the parameter when we unit test our ICommand implementations. Obviously, we could just pass in a new System.Object every time, but why not let AutoFixture take care of that for us?

(You may think that new'ing up a System.Object is something you can easily do yourself, but imagine other APIs that require much more complex input parameters, and you should begin to see the potential.)

Here's a state-based unit test that verifies that the Message property of the MyViewModel class has the correct value after the FooCommand has been invoked:

public void FooWillUpdateMessage()
    // Fixture setup
    var fixture = new Fixture();
    var sut = fixture.CreateAnonymous<MyViewModel>();
    // Exercise system
    fixture.Do((object parameter) => 
    // Verify outcome
    Assert.AreEqual("Foo", sut.Message, "Message");
    // Teardown

Notice how the Do method takes an Action<object> to specify the method to invoke. AutoFixture automatically supplies an instance for the parameter parameter using the same engine to create Anonymous variables that it uses for everything else.

The Do method in question is really a generic method with this signature:

public void Do<T>(Action<T> action);

There are also overloads that take two, three or four input parameters, corresponding to the available Action types available in the BCL.

These methods are simply convenience methods that allow you to express your test code more succinctly than you would otherwise have been able to do.

Dependency Injection Podcast with me

Tuesday, 17 November 2009 18:58:47 UTC

Daniel Frost has published a podcast where he discusses Dependency Injection with me. It's about half an hour long and in Danish. Hear it here.

Using Castle Windsor's PerWebRequest lifestyle with ASP.NET MVC on IIS7

Tuesday, 17 November 2009 12:44:37 UTC

When using Castle Windsor in web applications you would want to register many of your components with a lifestyle that is associated with a single request. This is the purpose of the PerWebRequest lifestyle.

If you try that with ASP.NET MVC on IIS7, you are likely to receive the following error message:

Looks like you forgot to register the http module Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule
Add '<add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.MicroKernel" />' to the <httpModules> section on your web.config.

Unfortunately, following the instructions in the error message doesn't help. There's a discussion about this issue on the Castle Project Users forum, but the gist of it is that if you don't need to resolve components during application startup, this shouldn't be an issue, and indeed it isn't - it seems to be something else.

In my case I seem to have solved the problem by registering the HTTP module in configuration/system.webServer/modules instead of configuration/system.web/httpModules.

Although I haven't had the opportunity to dive into the technical details to understand why this works, this seems to solve the problem on both Windows Vista and Windows Server 2008.


It is because IIS 7 running under Integration Pipeline(the default, and prefered mode) requires all HttpHandlers and HttpModules to be registered under:


It ignores the other HttpHandler and HttpModules defined in system.web.

If you have a website running under IIS6, or you have downgraded your IIS7 to run in "Classic .NET" pipeline mode, that's when you use /configuration/system.web/httpModules - as it's the OLD way of adding them.

IIS7 will even take your old web.config from IIS6 and 'upgrade it' by adding in the system.webServer/modules and /handlers section, and will copy over the older definitions. That is, if you use the IIS Manager to upgrade it. ;)
2010-01-14 22:04 UTC
Thanks for the explanation :)
2010-01-14 22:23 UTC

Creating length-constrained strings with AutoFixture

Saturday, 07 November 2009 19:56:05 UTC

The following feature suggestion was recently posted in the AutoFixture Issue Tracker board:

"We're using AutoFixture to create random rows of data in our DB. A lot of times though, it creates strings that are too long for the database columns. It would be nice if the .With<string> method had an overload that took in a min/max length. We want the random data, but capped at a limit.

"fixture.Build<MyObject>.With(x = x.MyString, 0, 100);

"As an aside, this is for a project that uses Nhibernate and Fluent Nhibernate, which has these lengths already defined. I would be nice if AutoFixture could automatically pick up on that somehow."

I think such an feature is an excellent idea, but I don't think I will include in AutoFixture. Why not?

So far, I have kept the AutoFixture API pretty clean and very generic, and it is my belief that this is one of the main reasons it is so expressive and flexible. There are no methods that only work on specific types (such as strings), and I am reluctant to introduce them now.

In the last six months, I have identified a lot of specialized usage idioms that I would love to package into a reusable library, but I think that they will pollute the core AutoFixture API, so I'm going to put those in one or more optional 'add-on' libraries.

The ability to define strings that are constrained on length could be one such feature, but rather than wait for a helper library, I will show you have you can implement such a method yourself.

The first thing we need is a method that can create anonymous strings given length constraints. One possible implementation is this ConstrainedStringGenerator class:

public class ConstrainedStringGenerator
    private readonly int minimumLength;
    private readonly int maximumLength;
    public ConstrainedStringGenerator(int minimumLength, 
        int maximumLength)
        if (maximumLength < 0)
            throw new ArgumentOutOfRangeException("...");
        if (minimumLength > maximumLength)
            throw new ArgumentOutOfRangeException("...");
        this.minimumLength = minimumLength;
        this.maximumLength = maximumLength;
    public string CreateaAnonymous(string seed)
        var s = string.Empty;
        while (s.Length < this.minimumLength)
            s += GuidStringGenerator.CreateAnonymous(seed);
        if (s.Length > this.maximumLength)
            s = s.Substring(0, this.maximumLength);
        return s;

The CreateAnonymous method uses AutoFixture's GuidStringGenerator class to create anonymous strings of the required length. For this implementation I chose a basic algorithm, but I'm sure you can create one that is more sophisticated if you need it.

The next thing we need to do is to implement the desired With method. That can be done with an extension method works on ObjectBuilder<T>:

public static class ObjectBuilderExtension
    public static ObjectBuilder<T> With<T>(
        this ObjectBuilder<T> ob,
        Expression<Func<T, string>> propertyPicker,
        int minimumLength,
        int maximumLength)
        var me = (MemberExpression)propertyPicker.Body;
        var name = me.Member.Name;
        var generator =
            new ConstrainedStringGenerator(
                minimumLength, maximumLength);
        var value = generator.CreateaAnonymous(name);
        return ob.With(propertyPicker, value);

The method takes the same input as ObjectBuilder<T>'s With method, plus the two integers that constrain the length. Note that the propertyPicker expression has been constrained to deal only with strings.

In this implementation, we use the ConstrainedStringGenerator class to generate the desired value for the property, where after we can use the existing With method to assign the value to the property in question.

This now allows us to write Build statements like the one originally requested:

var mc = fixture.Build<MyClass>()
    .With(x => x.SomeText, 0, 100)

The other part of the request, regarding NHibernate integration, I will leave to the interested reader - mostly because I have never used NHibernate, so I have no clue how to do it. I would, however, love to see a blog post with that addition.

This entire example is now part of the AutoFixture test suite, so if you are interested in looking at it in more detail, you can get it from the AutoFixture source code (available at CodePlex).


I see that you have added a ConstrainedStringGenerator class to AutoFixture now but I haven't found any example of how to use it in its new form. What I'm doing currently is providing an ICustomization implementation for domain data that takes max field lengths into consideration. My first question is, is this the right place to do that? If so, how do I reliably get the ISpecimenContext to pass to the Create method? Right now I am creating a SpecimenContext instance myself but again I'm not sure where I should be getting my ISpecimenBuilder instance to pass to it. The 2 leading candidates right now are the Engine property of a Fixture instance that I pass in the constructor as a ISpecimenBuilder or create a StringGenerator instance. If the StringGenerator is what I should use though what should I pass to it in its constructor? Here is an example in case that isn't clear.

x => x
.Without(m => m.CategoryID)
.Without(m => m.ProductSet)
.With(m => m.CategoryName, (String)stringGenerator.Create(new ConstrainedStringRequest(NwCategory.MaxLength_CategoryName), new SpecimenContext(this.SpecimenBuilder)))
2012-04-26 14:32 UTC
IIRC the ConstrainedStringGenerator class was added to support the [StringLength] attribute. Does this do what you'd like it to do?

There's also a recent discussion about the subject on Stack Overflow.

Finally, perhaps you'll find this post helpful.

If none of these links answer your question, please feel free to ask again. However, Stack Overflow or the AutoFixture discussion list might be better forums, as they are better targeted at Q&A.

2012-04-27 18:43 UTC

AutoFixture beta 1

Saturday, 31 October 2009 08:59:43 UTC

AutoFixture beta 1 is now available on the CodePlex site! We have been using AutoFixture quite intensively in Safewhere for almost half a year now, and the core of it has turned out to be stable and much more powerful than I originally imagined.

During that period, I have discovered and fixed a few bugs, but the most positive experience has been how extended usage has inspired us to come up with numerous ideas to new cool features. Some of these features are already implemented in the current release, and the rest are listed on the AutoFixture site.

The beta 1 release page has more details about this particular release.

Anonymous With

Monday, 26 October 2009 20:26:49 UTC

A few months ago I described how you can use AutoFixture's With method to assign property values as part of building up an anonymous variable. In that scenario, the With method is used to explicitly assign a particular, pre-defined value to a property.

There's another overload of the With method that doesn't take an explicit value, but rather uses AutoFixture to create an anonymous value for the property. So what's the deal with that if AutoFixture's default behavior is to assign anonymous values to all writable properties?

In short it's an opt-in mechanism that only makes sense if you decide to opt out of the AutoProperties features.

As always, let's look at an example. This time, I've decided to show you a slightly more realistic example so that you can get an idea of how AutoFixture can be used to aid in unit testing. This also means that the example is going to be a little more complex than usual, but it's still simple.

Imagine that we wish to test that an ASP.NET MVC Controller Action returns the correct result. More specifically, we wish to test that the Profile method on MyController returns a ViewResult with the correct Model (the current user's name, to make things interesing).

Here's the entire test. It may look more complicated than it is - it's really only 10 lines of code, but I had to break them up to prevent unpleasant wrapping if your screen is narrow.

public void ProfileWillReturnResultWithCorrectUserName()
    // Fixture setup
    var fixture = new Fixture();
    fixture.Customize<ControllerContext>(ob => ob
        .With(cc => cc.HttpContext));
    var expectedUserName = 
    var httpCtxStub = new Mock<HttpContextBase>();
    httpCtxStub.SetupGet(x => x.User).Returns(
        new GenericPrincipal(
            new GenericIdentity(expectedUserName), null));
    var sut = fixture.Build<MyController>()
        .With(c => c.ControllerContext)
    // Exercise system
    ViewResult result = sut.Profile();
    // Verify outcome
    var actual = result.ViewData.Model;
    Assert.AreEqual(expectedUserName, actual, "User");
    // Teardown

Apart from AutoFixture, I'm also making use of Moq to stub out HttpContextBase.

You can see the Anonymous With method in two different places: in the call to Customize and when the SUT is being built. In both cases you can see that the call to With follows a call to OmitAutoProperties. In other words: we are telling AutoFixture that we don't want any of the writable properties to be assigned a value except the one we identify.

Let me highlight some parts of the test.

fixture.Customize<ControllerContext>(ob => ob
    .With(cc => cc.HttpContext));

This line of code instructs AutoFixture to always create a ControllerContext in a particular way: I don't want to use AutoProperties here, because ControllerContext has a lot of writable properties of abstract types, and that would require me to set up a lot of Test Doubles if I had to assign values to all of those. It's much easier to simply opt out of this mechanism. However, I would like to have the HttpContext property assigned, but I don't care about the value in this statement, so the With method simply states that AutoFixture should assign a value according to whatever rule it has for creating instances of HttpContextBase.

I can now set up a Stub that populates the User property of HttpContextBase:

var httpCtxStub = new Mock<HttpContextBase>();
httpCtxStub.SetupGet(x => x.User).Returns(
    new GenericPrincipal(
        new GenericIdentity(expectedUserName), null));

This is registered with the fixture instance which closes the loop to the previous customization.

I can now create an instance of my SUT. Once more, I don't want to have to set up a lot of irrelevant properties on MyController, so I opt out of AutoProperties and then explicitly opt in on the ControllerContext. This will cause AutoFixture to automatically populate the ControllerContext with the HttpContext Stub:

var sut = fixture.Build<MyController>()
    .With(c => c.ControllerContext)

For completeness' sake, here's the MyController class that I am testing:

public class MyController : Controller
    public ViewResult Profile()
        object userName = this.User.Identity.Name;
        return this.View(userName);

This test may seem complex, but it really accomplishes a lot in only 10 lines of code, considering that ASP.NET MVC Controllers with a working HttpContext are not particularly trivial to set up.

In summary, this With method overload lets you opt in on one or more explicitly identified properties when you have otherwise decided to omit AutoProperties. As all the other Builder methods, this method can also be chained.

WCF Podcast with me

Saturday, 24 October 2009 01:52:18 UTC

Daniel Frost has published a podcast where he discusses WCF with me. It's about half an hour and in Danish. Hear it here.

Writing a book

Monday, 05 October 2009 18:13:50 UTC

For the last few months I've been writing a book for Manning tentatively titled Dependency Injection in .NET. The page about the book is now live at the Manning web site where you can read more about it and, if you would like, purchase an Early Access edition and read the chapters as they are being written.

If you have ever wanted to learn about Dependency Injection (DI) related to .NET, here's your chance!

At the moment I'm about a third of the way into the book, so there's still some way to go, but I hope to be done with it in 2010.

If you decide to purchase an Early Access edition, I'd love to receive your feedback in the online forum.


Ohh, I could have used this book weeks ago! I've been trying to wrap my head around DI/IoC for some time, and in fact am working on a blog post on the subject. It seems complex on the surface, but is less so once you really get into it!

Purchased the MEAP, looking forward to the results!
2009-10-07 03:01 UTC
I hope that you get a lot out of it! If parts of the contents strike you as odd or you think that something is missing, please let me know. The Author Online forum is the preferred place, but you can drop me a line in any way you prefer.
2009-10-13 11:00 UTC
Bill Campbell
Hey Mark,

Got the MEAP of your book and am enjoying it. I was wondering if you are going to make any of the sample code from the book available? That would be awesome.

2009-10-21 12:32 UTC
Yes, that is definitely the plan. Manning does have the code, but I don't know when they plan on making it available. It's still a little rough around the edges, but if you would like to get it now, send me an email (use the small envelope icon in the Contact section area) and I'll zip it up for you.
2009-10-21 12:55 UTC
Scott Peterson
Hello Mark,

While your book is now a couple of years old, I purchased an e-version of it and got a lot out of it. I saw immediate uses for interceptors in an application I am evaluating (for a re-write) at a new company, but I ran into some trouble.
In a copy of your ProductManagementClient code, in a MenuItem_Click event, I added code to purposefully throw an InvalidOperationException, one of the exception types listed in the ErrorHandlingInterceptor, just to see the interceptor in action. I then tried to step through the code, but I never got to the Interceptor; I always just see the standard Visual Studio exception dialog in Debug mode.
Am I approaching this incorrectly?

Thanks for all that you do for the .NET community; it has really been a big help to me.

2013-05-23 18:31 UTC

Scott, thanks for writing. The Visual Studio behaviour you describe fits my own experience: stepping into something Decorated with a dynamic interceptor doesn't really work. While I'm no expert in how the Visual Studio debugger works, I think it's because there's some auto-generated code (the dynamic interceptor(s)) between the call site and your code on the other side. Visual Studio doesn't have the source code for the dynamic interceptor, so it generally gives up when you try to do that.

However, if you set a breakpoint on the other side (behind the interceptors), you will still hit that breakpoint when you press F5. This should enable you to still 'see' the interceptor(s) in action, using the debugger. IIRC, you can also set breakpoints in your own interceptor code, and those should be hit as well.

As I wrote, I'm no expert in the Visual Studio debugger, but I do know that it has lots of options you can tweak. I wouldn't be surprised if there was an option that would enable you to skip over the interceptor code and into the code Decorated by the interceptor, but I don't know how to do that.

2013-05-23 19:07 UTC


Tuesday, 29 September 2009 19:38:42 UTC

The SOLID principles of OOD as originally put forth by Robert C. Martin make for such a catchy acronym, although they seem to originally have been spelled SOLDI.

In any case I've lately been thinking a bit about these principles and it seems to me that the Single Responsibility Principle (SRP) and the Interface Segregation Principle (ISP) seem to be very much related. In essence you could say that the ISP is simply SRP applied to interfaces.

The notion underlying both is that a type should deal with only a single concept. Whether that applies to the public API or the internal implementation is less relevant because a corollary to the Liskov Substitution Principle (LSP) and Dependency Inversion Principle (DIP) is that we shouldn't really care about the internals (unless we are actually implementing, that is).

The API is what matters.

Although I do understand the subtle differences between SRP and ISP I think they are so closely related that one of them is really redundant. We can remove the ISP and still have a fairly good acronym: SOLD (although SOLID is still better).

There's one principle that I think is missing from this set: The principle about Command/Query Separation (CQS). In my opinion, this is a very important principle that should be highlighted more than is currently the case.

If we add CQS to SOLD, we are left with some less attractive acronyms:


Not nearly as confidence-inspiring acronyms as SOLID, but nonetheless, I'm striving to write COLDS code.

Customizing A Type's Builder With AutoFixture

Tuesday, 22 September 2009 14:53:48 UTC

In the previous post on AutoFixture, I demonstrated how it's possible to use a customized Builder to perform complex initialization when requesting an instance of a particular type. To recap, this was the solution I described:

var mc = fixture.CreateAnonymous<MyClass>();
var mvm = fixture.Build<MyViewModel>()
    .Do(x => x.AvailableItems.Add(mc))
    .With(x => x.SelectedItem, mc)

This code first creates an anonymous instance of MyClass that can be added to MyViewModel. It then initializes a Builder for a specific instance of MyViewModel, instructing it to

  1. add the anonymous MyClass instance to the list of AvailableItems
  2. assign the same instance to the SelectedItem property

While this works splendidly, it can get tiresome to write the same customization over and over again if you need to create multiple instances of the same type. It also violate the DRY principle.

When this is the case, you can alternatively register a customized Builder pipeline for the type in question (in this case MyViewModel). This is done with the Customize method:

var mc = fixture.CreateAnonymous<MyClass>();
fixture.Customize<MyViewModel>(ob => ob
    .Do(x => x.AvailableItems.Add(mc))
    .With(x => x.SelectedItem, mc));

The Customize method takes as input a function that provides an initial ObjectBuilder as input, and returns a new, customized ObjectBuilder as output. This function is registered with the type, so that each time an anonymous instance of the type is requested, the customized ObjectBuilder will be used to create the instance.

In the example, I customize the supplied ObjectBuilder (ob) in exactly the same way as before, but instead of invoking CreateAnonymous, I simply return the customized ObjectBuilder to the Fixture instance. It then saves this customized ObjectBuilder for later use.

With this customization, what before failed now succeeds:

var mvm = fixture.CreateAnonymous<MyViewModel>();

The Customize method is the core method for customizing AutoFixture. Most other customization methods (like Register) are simply convenience methods that wraps Customize. It is a very powerful method that can be used to define some very specific Builder algorithms for particular types.


Scott Peterson

I posted this to CodePlex without properly thinking it through, but am now posting here which should be closer to where it belongs.

I have the following class that I am trying to test:

public class License
        public virtual DateTime DatePurchased { get; set; }
        public virtual int LicenseDuration { get; set; }
        public virtual EnumDatePeriod PeriodType { get; set; }
        public virtual bool InUse { get; set; }

        public DateTime ExpirationDate()
            ILicenseCalculator calculator = CreateLicenseDurationBuilder(PeriodType);

            return calculator.CalculateLicenseDuration(DatePurchased, LicenseDuration);

        public ILicenseCalculator CreateLicenseDurationBuilder(EnumDatePeriod datePeriod)
            Dictionary<EnumDatePeriod, ILicenseCalculator> calculators = new Dictionary<EnumDatePeriod, ILicenseCalculator>();
            calculators.Add(EnumDatePeriod.Year, new YearLicenseCalculator());
            calculators.Add(EnumDatePeriod.Month, new MonthLicenseCalculator());
            calculators.Add(EnumDatePeriod.Week, new WeekLicenseCalculator());
            calculators.Add(EnumDatePeriod.Day, new DayLicenseCalculator());

            return calculators[datePeriod];

Specifically, I want to see if I have a license that was purchased more than X time periods ago, the expiration date calculates properly. For example, I have a test that is set up to use a 6 month license, with a purchase date from seven months ago. I am trying to force a certain date, so I got into customizing, and set up my test as follows:

        public void CanCalculateExpirationDateOnExpiredMonthlyLicense()
            Fixture fixture = new Fixture();
            fixture.Customize<License>(x => x
                .With(b => b.DatePurchased == DateTime.Now.AddMonths(-7)));
            var sut = fixture.Create<License>();

I realize that this isn't a complete test, but I ran it just to see what feedback I'd get, to make certain I was customizing properly. Looks like I'm not, because I get an error:

Result Message:    
System.ArgumentException : The expression's Body is not a MemberExpression. Most likely this is because it does not represent access to a property or field. 
Parameter name: propertyPicker 

Where have I gone wrong?

Thanks for your help.

2015-02-26 21:39 UTC

Scott, thank you for writing. In your expression b.DatePurchased == DateTime.Now.AddMonths(-7), what would you say the == does?

2015-02-27 7:35 UTC
Scott Peterson

Mark, I really must apologize; my post above was not meant to be published. I worked on this a long time ago and I must have committed it to my local repository. I am very aware of the difference between = and ==. This must have been a question I had when I first started looking at AutoFixture (and working with Git). Again, my apologies.


2015-03-01 19:41 UTC

Page 44 of 49

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