Windows Azure migration smell: SQL Server over-utilization

Monday, 02 May 2011 12:23:49 UTC

Recently I partook in a Windows Azure migration workshop, helping developers from existing development organizations port their applications to Windows Azure. Once more an old design smell popped up: SQL Server over-utilization. This ought to be old news to anyone with experience designing software on the Wintel stack, but apparently it bears repetition:

Don't put logic in your database. SQL Server should be used only for persistent storage of data.

(Yes: this post is written in 2011…)

Many years ago I heard that role described as a ‘bit bucket' - you put in data and pull it out again, and that's all you do. No fancy stored procedures or functions or triggers.

Why wouldn't we want to use the database if we have one? Scalability is the answer. SQL Server doesn't scale horizontally. You can't add more servers to take the load off a database server (well, some of my old colleagues will argue that this is possible with Oracle, and that may be true, but with SQL Server it's impossible).

Yes, we can jump through hoops like partitioning and splitting the database up into several smaller databases, but it still doesn't give us horizontal scalability. SQL Server is a bottleneck in any system in which it takes part.

How is this relevant to Windows Azure? It's relevant for two important reasons:

  • There's an upper size limit on SQL Azure. Currently that size limit is 50 GB, and while it's likely to grow in the future, there's going to be a ceiling for a long time.
  • You can't fine tune the hardware for performance. The server runs on virtual hardware.

Development organizations that rely heavily on the database for execution of logic often need expensive hardware and experienced DBAs to squeeze extra performance out of the database servers. Such people know that write-intensive/append-only tables work best with one type of RAID, while read-intensive tables are better hosted on other file groups on different disks with different RAID configurations.

With SQL Azure you can just forget about all that.

The bottom line is that there are fundamental rules for software development that you must follow if you want to be able to successfully migrate to Windows Azure. I previously described an even simpler sanity check you should perform, but after that you should take a good look at your database.

The best solution is if you can completely replace SQL Server with Azure's very scalable storage services, but those come with their own set of challenges.

Feedback mechanisms and tradeoffs

Friday, 29 April 2011 13:02:14 UTC

Rapid feedback is one of the cornerstones of agile development. The faster we can get feedback, the less it costs to correct errors. Unit testing is one of the ways to get feedback, but not the only one. Each way we can get feedback comes with its own advantages and disadvantages.

In my experience there's a tradeoff between the cost of setting up a feedback mechanism and the level of confidence we can get from it. This is quite intuitive to most people, but I've rarely seen it explicitly described. The purpose of this post is to explicitly describe and relate those different mechanisms.


In compiled languages, compilation provides the first level of feedback. I think a lot of people don't think about this as feedback as (for compiled languages) it's a necessary step before the code can be executed.

The level of confidence may not be very high - we tend to laugh at statements like ‘if it compiles, it works'. However, the compiler still catches a lot of mistakes. Think about it: does your code always compile, or do you sometimes get compilation errors? Do you sometimes try to compile your code just to see if it's possible? I certainly do, and that's because the compiler is always available, and it's the first and fastest level of feedback we get.

Code can be designed to take advantage of this verification step. Constructor Injection, for example, ensures that we can't create a new instance of a class without supplying it with its required dependencies.

It's also interesting to note that anecdotal evidence seems to suggest that unit testing is more prevalent for interpreted languages. That makes a lot of sense, because as developers we need feedback as soon as possible, and if there's no compiler we must reach for the next level of feedback mechanism.

Static code analysis

The idea of static code analysis isn't specific to .NET, but in certain versions of Visual Studio we have Code Analysis (which is also available as FxCop). Static code analysis is a step up from compilation - not only is code checked for syntactical correctness, but it's also checked against a set of known anti-patterns and idioms.

Static code analysis is encapsulated expert knowledge, yet surprisingly few people use it. I think part of the reason for this is because the ratio of time against confidence isn't as compelling as with other feedback mechanism. It takes some time to run the analysis, but like compilation the level of confidence gained from getting a clean result is not very high.

Personally, I use static code analysis once in a while (e.g. before checking in code to the default branch), but not as often as other feedback mechanisms. Still, I think this type of feedback mechanism is under-utilized.

Unit testing

Running a unit test suite is one of the most efficient ways to gain rapid feedback. The execution time is often comparable to running static code analysis while the level of confidence is much higher.

Obviously a successful unit test execution is no guarantee that the final application works as intended, but it's a much better indicator than the two previous mechanisms. When presented with the choice of using either static code analysis or unit tests, I prefer unit tests every time because the confidence level is much higher.

If you have sufficiently high code coverage I'd say that a successful unit test suite is enough confidence to check in code and let continuous integration take care of the rest.

Keep in mind that continuous integration and other types of automated builds are feedback mechanisms. If you institute rules where people are ‘punished' for checking in code that breaks the build, you effectively disable the automated build as a source of feedback.

Thus, the rest of these feedback mechanisms should be used rarely (if at all) on developer work stations.

Integration testing

Integration testing comes in several sub-categories. You can integrate multiple classes from within the same library, or integrate multiple libraries while still using Test Doubles instead of out-of-process resources. At this level, the cost/confidence ratio is comparable to unit testing.

Subcutaneous testing

A more full level of integration testing comes when all resources are integrated, but the tests are still driven by code instead of through the UI. While this gives a degree of confidence that is close to what you can get from a full systems test, the cost of setting up the entire testing environment is much higher. In many cases I consider this the realm of a dedicated testing department, as it's often a full-time job to maintain the suite of automation tools that enable such tests - particularly if we are talking about distributed systems.

System testing

This is a test of the full system, often driven through the UI and supplemented with manual testing (such as exploratory testing). This provides the highest degree of confidence, but comes with a very high cost. It's often at this level we find formal acceptance tests.

The time before we can get feedback at this level is often considerable. It may take days or even weeks or months.

Understand the cost/confidence ratio

The purpose of this post has been to talk about different ways we can get feedback when developing software. If we could get instantaneous feedback with guaranteed confidence it would be easy to choose, but as this is not the case we must understand the benefits and drawbacks of each mechanism.

It's important to realize that there are many mechanisms, and that we can combine them in a staggered approach where we start with fast feedback (like the compiler) with a low degree of confidence and then move through successive stages that each provide a higher level of confidence.


Markus Hjärne
Hi Mark, good post. I just thought of one thing worth mentioning in this context: guarding public APIs with checks that throws exceptions in case they fail and guarding private methods with asserts has been a great source of good and fast feedback for me over the years.

2011-05-04 20:46 UTC
I totally agree, and I was (and am still) planning on writing something about that in a later post. This is essentially the Fail Fast principle, but as for feedback mechanisms, we don't discover these Guard Clauses before we invoke them.

My strong preference is for writing unit tests that invoke these Guard Clauses to verify that they work, and that means that as far as feedback mechanisms go, they fall into the unit testing 'bucket'.
2011-05-04 20:54 UTC
Your comments about compilation are interesting, I hadn't thought of it before but it is a level of feedback that I find as useful as you do.

I wonder if you'd consider IntelliSense as an even earlier form of feedback though?

2012-06-25 09:20 UTC
IntelliSense is, I think, more of a learning tool. It's not really feedback about what you did - it's more information about what you can do. It's certainly a productivity feature, although there are some people who argue that it does more harm than good.
2012-06-25 10:50 UTC
It might be worth considering a couple of additional feedback mechanisms at the opposite end of the spectrum, in the sense that they provide even later feedback, if only to underscore your points from the article with extreme counter-examples. Run-time exceptions are themselves a feedback mechanism. Most unnecessarily "stringly-typed" code could be considered to be pushing code away from the more rapid, desirable feedback mechanisms. (Primitive Obsession in general might be considered another tendency which pushes the design of code toward being run-time exception-prone.) Logic erors are flaws in code with which the code appears to execute successfully, until the program output is manually inspected. Just off the cuff, one typical cause might be the tendency in some projects to add guard clauses such as if (methodArg==null) return; which causes methods to silently and unexpectedly return without accomplishing the task that they were designed to do. Mathematical calculations performed without adequate test coverage might be another example.

We learned about 3 classes of errors in school: 1) Syntax, 2) Run-time, and 3) Logic (Unit testing and static code analysis weren't as much of a thing back then). It might seem odd to discuss types of feedback mechanisms that are undesirable by definition, until you stop to observe how common it is for the design of much code to push errors towards this undesirable side of the continuum. "To defeat your enemy you first must know him" or something like that.
2016-09-11 00:11 UTC

David, thank you for making these feedback cases explicit. When I originally wrote this article, I implicitly had such alternative, common-place feedback mechanisms in mind, but I never explicitly spelled them out. While I should have done that, I can now thank you for doing it; your comment is a good addition to the original article.

2016-09-11 08:07 UTC

Provider is not a pattern

Wednesday, 27 April 2011 12:14:52 UTC

Developers exposed to ASP.NET are likely to be familiar with the so-called Provider pattern. You see it a lot in that part of the BCL: Role Provider, Membership Provider, Profile Provider, etc. Lots of text has already been written about Providers, but the reason I want to add yet another blog post on the topic is because once in a while I get the question on how it relates to Dependency Injection (DI).

Is Provider a proper way to do DI?

No, it has nothing to do with DI, but as it tries to mimic loose coupling I can understand the confusion.

First things first. Let's start with the name. Is it a pattern at all? Regular readers of this blog may get the impression that I'm fond of calling everything and the kitchen sink an anti-pattern. That's not true because I only make that claim when I'm certain I can hold that position, so I'm not going to denounce Provider as an anti-pattern. On the contrary I will make the claim that Provider is not a pattern at all.

A design pattern is not invented - it's discovered as a repeated solution to a commonly recurring problem. Providers, on the other hand, were invented by Microsoft, and I've rarely seen them used outside their original scope. Secondly I'd also dispute that they solve anything.

That aside, however, I want to explain why Provider is bad design:

  • It uses the Constrained Construction anti-pattern
  • It hides complexity
  • It prevents proper lifetime management
  • It's not testable

In the rest of this post I will explain each point in detail, but before I do that we need an example to look at. The old OrderProcessor example suffices, but instead of injecting IOrderValidator, IOrderCollector, and IOrderShipper this variation uses Providers to provide instances of the Services:

public SuccessResult Process(Order order)
    IOrderValidator validator = 
    bool isValid = validator.Validate(order);
    if (isValid)
    return this.CreateStatus(isValid);

The ValidatorProvider uses the configuration system to create and return an instance of IOrderValidator:

public static IOrderValidator Validator
        var section = 
        var typeName = section.ValidatorTypeName;
        var type = Type.GetType(typeName, true);
        var obj = Activator.CreateInstance(type);
        return (IOrderValidator)obj;

There are lots of details I omitted here. I could have saved the reference for later use instead of creating a new instance each time the property is accessed. In that case I would also have had to make the code thread-safe, so I decided to skip that complexity. The code could also be more defensive, but I'm sure you get the picture.

The type name is defined in the app.config file like this:

        Ploeh.Samples.OrderModel.UnitTest" />

Obviously, CollectorProvider and ShipperProvider follow the same… blueprint.

This should be well-known to most .NET developers, so what's wrong with this model?

Constrained Construction

In my book's chapter on DI anti-patterns I describe the Constrained Construction anti-pattern. Basically it occurs every time there's an implicit constraint on the constructor of an implementer. In the case of Providers the constraint is that each implementer must have a default constructor. In the example the culprit is this line of code:

var obj = Activator.CreateInstance(type);

This constrains any implementation of IOrderValidator to have a default constructor, which obviously means that the most fundamental DI pattern Constructor Injection is out of the question.

Variations of the Provider idiom is to supply an Initialize method with a context, but this creates a temporal coupling while still not enabling us to inject arbitrary Services into our implementations. I'm not going to repeat six pages of detailed description of Constrained Construction here, but the bottom line is that you can't fix it - you have to refactor towards true DI - preferably Constructor Injection.

Hidden complexity

Providers hide the complexity of their implementations. This is not the same as encapsulation. Rather it's a dishonest API and the problem is that it just postpones the moment when you discover how complex the implementation really is.

When you implement a client and use code like the following everything looks deceptively simple:

IOrderValidator validator = 

However, if this is the only line of code you write it will fail, but you will not notice until run-time. Check back to the implementation of the Validator property if you need to refresh the implementation: there's a lot of things that can go wrong here:

  • The appropriate configuration section is not available in the app.config file.
  • The ValidatorTypeName is not provided, or is null, or is malformed.
  • The ValidatorTypeName is correctly formed, but the type in question cannot be located by Fusion.
  • The Type doesn't have a default constructor. This is one of the other problems of Constrained Construction: it can't be statically enforced because a constructor is not part of an abstraction's API.
  • The created type doesn't implement IOrderValidator.

I'm sure I even forgot a thing or two, but the above list is sufficient for me. None of these problems are caught by the compiler, so you don't discover these issues until you run an integration test. So much for rapid feedback.

I don't like APIs that lie about their complexity.

Hiding complexity does not make an API easier to use; it makes it harder.

An API that hides necessary complexity makes it impossible to discover problems at compile time. It simply creates more friction.

Lifetime management issues

A Provider exerts too much control over the instances it creates. This is a variation of the Control Freak anti-pattern (also from my book). In the current implementation the Validator property totally violates the Principle of least surprise since it returns a new instance every time you invoke the getter. I did this to keep the implementation simple (this is, after all, example code), but a more normal implementation would reuse the same instance every time.

However, reusing the same instance every time may be problematic in a multi-threaded context (such as a web application) because you'll need to make sure that the implementation is thread-safe. Often, we'd much prefer to scope the lifetime of the Service to each HTTP request.

HTTP request scoping can be built into the Provider, but then it would only work in web applications. That's not very flexible.

What's even more problematic is that once we move away from the Singleton lifestyle (not to be confused with the Singleton design pattern) we may have a memory leak at hand, since the implementation may implement IDisposable. This can be solved by adding a Release method to each Provider, but now we are moving so far into DI Container territory that I find it far more reasonable to just use proper DI instead of trying to reinvent the wheel.

Furthermore, the fact that each Provider owns the lifetime of the Service it controls makes it impossible to share resources. What if the implementation we want to use implements several Role Interfaces each served up by a different Provider? We might want to use that common implementation to share or coordinate state across different Services, but that's not possible because we can't share an instance across multiple providers.

Even if we configure all Providers with the same concrete class, each will instantiate and serve its own separate instance.


The Control Freak also impacts testability. Since a Provider creates instances of interfaces based on XML configuration and Activator.CreateInstance, there's no way to inject a dynamic mock.

It is possible to use hard-coded Test Doubles such as Stubs or Fakes because we can configure the XML with their type names, but even a Spy is problematic because we'll rarely have an object reference to the Test Double.

In short, the Provider idiom is not a good approach to loose coupling. Although Microsoft uses it in some of their products, it only leads to problems, so there's no reason to mimic it. Instead, use Constructor Injection to create loosely coupled components and wire them in the application's Composition Root using the Register Resolve Release pattern.


I have to disagree with your statement that the provider is not a pattern at all. The provider (in .NET) is a specific implementation of the bridge pattern as defined in "Design Patterns" by Gamma, Helm, Johnson, and Vlissides. I believe that this description has been lost over the past 10 years as people in the industry have resorted to calling it the "Provider Pattern."

When used correctly as a bridge pattern, the provider does actually solve reoccuring problems very eloquently. It decouples the interface from the implementation so that the implementation details are hidden from the client. You can extend the implementation by building on existing implementations to reduce the complexity. Complexity is only introduced as a by-product of bad design.

The notion that the provider interfers with testability is incorrect. Each individual implementation should be designed from the beginning to be testable. The bridge is not the entry point for testing the implementor. The bridge should only be responsible for forwarding client requests to its implementor. (Therefore the bridge should be testable as well.) I am not stating that there aren't providers out there that violate this priciple. I'm merely stating that providers which do this are poorly designed.
2011-06-27 16:43 UTC
I just reread the Bridge pattern and while I agree that Provider is a specialization of Bridge, I don't agree that this relationship goes the other way. If you read the description of Provider provided in the link above, you'll notice that it goes into very specific details on how a Provider should be implemented, including how it should be backed by the configuration system and that it must be created by clients by a static factory.

This goes way beyond what the Bridge pattern describes, so I hardly think you can equate the two.

Especially the part about being created by a static factory which can only read from the configuration system is testability poison.
2011-06-27 19:25 UTC
I disagree with your analysis. Provider model is a pattern.

I realize this is a year late, but I just found your article a few days ago via a reference on scott hanselmans blog (in comments). Here is my rebuttal.
2012-06-29 11:31 UTC
Also going to throw in on the disagreement with your assertion:

"A design pattern is not invented - it's discovered as a repeated solution to a commonly recurring problem."

The design pattern concept does not provide an opinion on how they were arrived upon. I am always delighted when programming terminology gives me new insight into words. Kinda like "abstraction" -- I don't think I would even know the term if I were not a programmer, at least, not as well as I do.

However, programming has little to teach us about the words "design" and "pattern" that we do not already know. There is nothing mysterous or supernatural about them, even when combined. A pattern is anything that repeats in a predictable fashion.. and that's really all there is to it.

Whether or not the service provider is a good pattern, I am not sure, but I can be certain that it is, in fact, a pattern. Isn't the neuance you're describing subjective, anyway? Suppose that you invented it, and then I used it. Suppose also that a third developer "discovered" our usage. What then, does the universe unwind? My example is trivial, but scale it up and it makes a little more sense.

But, I do love your blog, thank you for the discussion.
2014-11-11 9:55 UTC

Luke, thank you for writing. Obviously, you are free to have your own opinions, and interpretation of various words. However, if we want to be able to discuss our trade in a concise manner, we need as precise a vocabulary as possible.

On this blog (and elsewhere), I strive to use a consistent and well-known jargon. Thus, when I use the term design pattern, I refer to it in a way that's compatible with the original description in Design Patterns. In the introduction (on page 2), Gamma et al. write:

"None of the design patterns in this book describes new or unproven designs. We have included only designs that have been applied more than once in different systems."
(Emphasis mine.) The point is that, using the established vocabulary, a design pattern most certainly implies that the pattern is a result of parallel evolution, and subsequently discovered and described as a common solution to a particular type of problem.

Although I grant that it's partially subjective, there's still an implicit value judgement in cataloguing a design pattern. While most patterns come with a set of known disadvantages, but those disadvantages tend to not outweigh the benefits. If they did, it wouldn't be a design pattern, but rather an anti-pattern. This, too, is a well-defined term:

"a commonly occurring solution to a problem that generates decidedly negative consequences."
This definition differs from a 'proper' design pattern because a design pattern has mostly beneficial consequences.

2014-11-14 20:32 UTC

I appreciate your effort to maintain consistent jargon and termonology. I have had dozens of heated arguments with my co-workers about individual words in our interfaces, all the while they're staring back at me with a look that says "omg dude, its just a word." I gather that you and I have that common.

Personally, I'm against the concept of jargon all together because it, by its nature, can only create confusion. By that I mean, if it is consistent with the English language, then its not jargon, its just English. Conversely, if it contradicts or conflicts with the English language, then its bad jargon anyway, and can only lead to confusion. I tend to err on the side of verbosity, and might have described the pattern as not being a "Beneficial Design Pattern".

In reading the paragraph you quoted from, I did not get the impression that the author gave an opinion on the origin of a pattern as a contributor to its validity. I think he is simply trying to disclaim the notion that the patterns described within the book are original ideas, and effort was made to only include patterns that have been implemented in the wild, and by more than one implementor. i.e. I did not write a book about my own patterns, or the clever things my co-workers have done.

"So although these designs are not new, we capture them in a new and accessible way: as a catalog of design patterns having a consistent format."

The service pattern certainly has been implemented by more than one implementor, sometimes identified by a different name, sometimes in such a way that provides more benefit than otherwise, and very likely before Microsoft introduced it to the world at-large.

My critique of your article was based solely on the language used and only because of provocativeness of your statement. It seemed intentionally unintuitive.

With all of that said, though, I concede my point. I do that mostly because you obviously have a superior understanding of design patterns than I do (by multitudes). Your blog is one of resources that first got me interested in the study of design patterns, and I've learned a great deal from it. I think it would be rather foolish for me to try to "take you on", as I'd certainly be embarrassed.

Besides that, I could not formulate an opinion on the supporting arguments you put forth as I reread the blog. I have not programmed in .NET in a very long time and I have trouble understanding if we're even referring to the same things. I fear that I am a bit out of my league.

My [perhaps misguided] interpretation of the "Service Pattern" comes from places wholy unrelated to .NET. I've seen the term used to describe a pattern akin to the "Adapter Pattern", where the term "Adapter" is replaced by "Service", and "Adaptee" is replaced by "Provider".

Implementor < Service < Provider (or ServiceProvider)


Model < StorageService < MySQLProvider

Thank you for your thoughtful response.

2014-11-15 3:10 UTC

At the risk of coming across as a pedant, did you mean Provider when you wrote "Service Pattern"? At least, I'm not aware of any Service Pattern in the most commonly accepted pattern literature, but perhaps there's a book I should read.

The Provider design isn't the same as the Adapter pattern. The difference is, among others, that Providers rely on the .NET configuration system, as well as the Constrained Construction anti-pattern. Particularly its reliance on the .NET configuration system is what excludes it from being a proper pattern, because you couldn't possibly discover it on a different platform.

The Adapter pattern describes how to adapt one API to another API; while it's a useful pattern, it has a different concern than Provider. It also doesn't prescribe any particular method of initialization.

2014-11-15 20:53 UTC

AutoFixture 2.1 beta 1

Tuesday, 19 April 2011 14:05:11 UTC

It gives me great pleasure to announce that AutoFixture 2.1 beta 1 is now available for download. Compared to version 2.0 this release mostly contains added features as well as a few bug fixes. The release page contains a list of the new features.

The general availability of beta 1 of AutoFixture 2.1 marks the beginning of a trial period. If no new issues are reported within the next few weeks, a final version 2.1 will be released. If too many issues are reported, a new beta version may be necessary.

Please report any issues you find.

NuGet packages will follow the RTW version.

Constructor strategies for AutoFixture

Tuesday, 19 April 2011 06:59:19 UTC

When AutoFixture creates complex objects it invokes the constructors of the types in question. When a class exposes more than one constructor, the default behavior is to pick the constructor with the fewest number  of arguments. This is the exact opposite of most DI Containers that select the greediest constructor.

For a DI Container it makes more sense to select the greediest constructor because that maximizes the chance that all dependencies are properly being auto-wired.

The reason that AutoFixture's default behavior is different is that it maximizes the chance that an object graph can be created at all. If a convenience overload is available, this gives AutoFixture a better chance to compose the object graph.

This works well until a class comes along and introduces the wrong kind of ambiguity. Consider this case of Bastard Injection (Dependency Injection in .NET, section 5.2):

public class Bastard
    private readonly IFoo foo;
    public Bastard()
        : this(new DefaultFoo())
    public Bastard(IFoo foo)
        if (foo == null)
            throw new ArgumentNullException("foo");
 = foo;
    public IFoo Foo
        get { return; }

By default AutoFixture will use the default constructor which means that the Foo will always be the instance of DefaultFoo owned by the Bastard class itself. This is problematic if we wish to inject and freeze a Test Double because even if we freeze an IFoo instance, it will never be injected because the default constructor is being invoked.

var fixture = new Fixture();
var b = fixture.CreateAnonymous<Bastard>();

As the above unit test demonstrates, even though the Register method call defines a mapping from IFoo to DummyFoo, the Foo property is an instance of DefaultFoo. The DummyFoo instance is never injected into the Bastard instance since the default constructor is used.

Your first reaction in such a case should be to get rid of all convenience constructors to make the the class' constructor unambiguous. However, it's also possible to change AutoFixture's behavior.

The following is a description of a feature that will be a available in AutoFixture 2.1. It's not available in AutoFixture 2.0, but is already available in the code repository. Thus, if you can't wait for AutoFixture 2.1 you can download the source and build it.

As always, AutoFixture's very extensible interface makes it possible to change this behavior. Constructor selection is guided by an interface called IConstructorQuery, and while ModestConstructorQuery is the default implementation, there's also an implementation called GreedyConstructorQuery.

To change the behavior specifically for the Bastard class the Fixture instance must be customized. The following unit test demonstrates how to do that.

var fixture = new Fixture();
fixture.Customize<Bastard>(c => c.FromFactory(
    new MethodInvoker(
        new GreedyConstructorQuery())));
var b = fixture.CreateAnonymous<Bastard>();

Notice that the only difference from before is an additional call to the Customize method where Bastard is modified to use greedy constructor selection. This changes the factory for the Bastard type, but not for any other types.

If you'd rather prefer to completely change the overall constructor selection behavior for AutoFixture you can add the GreedyConstructorQuery wrapped in a MethodInvoker to the Fixture's Customizations:

var fixture = new Fixture();
    new MethodInvoker(
        new GreedyConstructorQuery()));
var b = fixture.CreateAnonymous<Bastard>();

In this unit test, the only change from the previous is that instead of assigning the GreedyConstructorQuery specifically to Bastard, it's now assigned as the new default strategy. All specimens created by AutoFixture will be created by invoking their most greedy constructor.

As always I find the default behavior more attractive, but the option to change behavior is there if you need it.


I seem to encountered a bug. It seems that the greedy constructor query & OmitAutoProperties don't play nice together when the constructor parameters fill in properties.
I've submitted an issue for this: Issue#320
  1. namespace JustATest
  2. {
  3. using Ploeh.AutoFixture;
  4. using Ploeh.AutoFixture.Kernel;
  6. using Xunit;
  8. public class JustATest {
  10. [Fact]
  11. public void GreedyConstructorAndOmitAutoProps() {
  12. var fixture = new Fixture();
  13. fixture.Customize<Foo>(c => c.FromFactory(
  14. new MethodInvoker(
  15. new GreedyConstructorQuery())));
  16. fixture.Customize<Foo>(c => c.OmitAutoProperties());
  18. var foo = fixture.Create<Foo>();
  19. Assert.NotNull(foo.myStr);
  20. }
  21. }
  23. public class Foo {
  24. public Foo(string myStr) {
  25. this.myStr = myStr;
  26. }
  28. public Foo() {
  29. }
  31. public string myStr { get; set; }
  32. }
  33. }
2014-10-17 6:48 UTC

Wes, thank you for writing. Let's continue the discussion over at that GitHub issue.

2014-10-18 8:26 UTC

Enumerables are dynamic - also in AutoFixture

Monday, 18 April 2011 13:22:29 UTC

I just got a question about AutoFixture's way of dealing with enumerables, and since I suspect this is something that might surprise a few people I found it reasonable to answer in a blog post.

In short, this unit test succeeds:

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

If this doesn't surprise you, then read the assertion again. The sequence is expected to not equal itself!

This behavior is by design.

(I've always wanted to write that.) The reason is that the return type of the CreateMany method is IEnumerable<T>, and that interface makes no guarantee that it will return the same sequence every time you iterate over it. The implementation may be a Generator.

According to its principle of Constrained Non-determinism, AutoFixture goes to great lengths to ensure that since IEnumerable<T> might be non-deterministic, it will be. This can be very useful in flushing out incorrect assumptions made by the SUT.

This behavior is carried forward by the MultipleCustomization. This unit test also succeeds:

var fixture = new Fixture()
    .Customize(new MultipleCustomization());
var expected =

The behavior is the same because with the MultipleCustomization IEnumerable<T> acts as a relationship type. The class responsible for this behavior is called FiniteSequenceRelay, but AutoFixture 2.1 will also ship with an alternative StableFiniteSequenceRelay which wraps the sequence in a List<T>.

To change the default behavior you can add the StableFiniteSequenceRelay to a Fixture's customizations:

var fixture = new Fixture();
var stableRelay = new StableFiniteSequenceRelay();
var expected =

The above unit test succeeds. Notice that the assertion now verifies that the sequence of strings is equal to itself.

Just like MultipleCustomization the StableFiniteSequenceRelay class will be available in AutoFixture 2.1, but is not availale in 2.0.

As always, it's best to encapsulate this behavior change into a Customization:

public class StableFiniteSequenceCustomization :
    public void Customize(IFixture fixture)
        var stableRelay = 
            new StableFiniteSequenceRelay();

This makes it easier to bundle it with the MultipleCustomization if we want all the other benefits of conventions for multiples:

public class StableMultipeCustomization : 
    public StableMultipeCustomization()
        : base(
            new StableFiniteSequenceCustomization(),
            new MultipleCustomization())

With the StableMultipleCustomization the following unit test now passes:

var fixture = new Fixture()
    .Customize(new StableMultipeCustomization());
var expected =

I still prefer the default behavior for its potential to act as an early warning system, but as I realize that this behavior may be problematic in some scenarios, the StableFiniteSequenceRelay provides an easy way to change that behavior.

Update (2011.8.10): StableFiniteSequenceCustomization is now part of AutoFixture and will be available in AutoFixture 2.2.


hello Mark, first of all thanks for a great library! I've been looking for something like AutoFixture.
Can you please clarify, what do I need to do to make following scenario work:
I have two classes, Stock and StockMarket, which are in many2many relationship (each has collection of other one). I want to use AutoFixture with Fluent NHibernate persistence specification for tests, but exception tells me: Ploeh.AutoFixture.ObjectCreationException: AutoFixture was unable to create an instance of type System.RuntimeType because the traversed object graph contains a circular reference
2012-02-27 18:18 UTC
Circular references are, IMO, a design smell, but since you are attempting to work with relational data, I guess you can't change the design.

The easiest way to get around an issue like that is to customize the types to not fill in the properties in question. Something like this:

fixture.Customize<Stock>(c => c.Without(s => s.StockMarket));

fixture.Customize<StockMarket>(c => c.Without(sm => sm.Stock));
2012-02-27 19:15 UTC
Thanks, I'll look into that
2012-02-28 05:10 UTC
Diogo Castro
Great blog post! I love the idea of making IEnumerable<T> non-deterministic. The fact that two traversals might yield different results is often overlooked by most people (me included). Luckily ReSharper reminds me when I'm iterating through an enumerable twice within the same scope, and having AutoFixture slap me across the face would be even better.

It appears that the default behaviour has changed since this post was written nearly 4 years ago. The test now fails.
If I may ask, why the change of heart?
2015-01-15 17:32 UTC

Diogo, thank you for writing. The reason for the changed behaviour was that the old behaviour caused too much confusion. Essentially, you can boild down the problem to the fact that if you compare 'two' IEnumerable<T> instances with ReferenceEquals, it could evaluate to true, and still contain different values when you start enumerating over them.

In AutoFixture 3, we did some tweaks to make the default experience with AutoFixture more intuitive, i.e. aiming for the Pit of Success. Our experience was that dynamic enumerables constantly tripped up people, including ourselves!

The old behaviour is still available as FiniteSequenceRelay, if you want to reinstate it. Just add a FiniteSequenceRelay instance to your Fixture's Customizations collection.

2015-01-15 19:11 UTC

MSDN Magazine article about CQRS on Windows Azure

Tuesday, 05 April 2011 19:52:57 UTC

My latest MSDN Magazine article, this time about CQRS on Windows Azure, is now available at the April MSDN Magazine web site.

It's mostly meant as an introduction to CQRS as well as containing some tips and tricks that are specific to applying CQRS on Windows Azure.

As an added bonus the code sample download contains lots of idiomatic unit tests written with AutoFixture's extensions, so if you'd like to see the result of my TDD work with AutoFixture, there's a complete code base to look at there.


Good article and also great sample code !
2011-04-11 06:45 UTC
Excellent article.
2011-04-14 14:54 UTC
Really enjoying the article, Mark. I was racking my brain at lunch thinking about some of these issues, regarding safe modification of state, etc. Then, I found the article.

I may end up doing things with Node and Redis, but still wanting to learn how to do things with Azure.
2012-11-30 19:10 UTC

Commands are Composable

Tuesday, 22 March 2011 13:09:25 UTC

A few months back I wrote a (somewhat theoretical) post on composable interfaces. A major point of that post was that Role Interfaces  with a single Command method (i.e. a method that returns no value) is a very versatile category of abstraction.

Some of my readers asked for examples, so in this post I will provide a few. Consider this interface that fits the above description:

public interface IMessageConsumer<T>
    void Consume(T message);

This is a very common type of interface you will tend to encounter a lot in distributed, message-based architectures such as CQRS or Udi Dahan's view of SOA. Some people would call it a message subscriber instead…

In the rest of this post I will examine how we can create compositions out of the IMessageConsumer<T> interface using (in order of significance) Decorator, Null Object, Composite, and other well-known programming constructs.


Can we create a meaningful Decorator around the IMessageConsumer<T> interface? Yes, that's easy - I've earlier provided various detailed examples of Decorators, so I'm not going to repeat them here.

I've yet to come up with an example of an interface that prevents us from applying a Decorator, so it's a valid falsifiable claim that we can always Decorate an interface. However, I have yet to prove that this is true, so until now we'll have to call it a conjecture.

However, since it's so easy to apply a Decorator to an interface, it's not a particularly valuable trait when evaluating the composability of an interface.

Null Object

It can be difficult to implement the Null Object pattern when the method(s) in question return a value, but for Commands it's easy:

public class NullMessageConsumer<T> : IMessageConsumer<T>
    public void Consume(T message)

The implementation simply ignores the input and does nothing.

Once again my lack of formal CS education prevents me from putting forth a formal proof, but I strongly suspect that it's always possibly to apply the Null Object pattern to a Command (keep in mind that out parameters count as output, so any interface with one or more of these are not Commands).

It's often valuable to be able to use a Null Object, but the real benefit comes when we can compose various implementations together.


To be truly composable, an interface should make it possible to create various concrete implementations that each adhere to the Single Responsibility Principle and then compose those together in a complex implementation. A Composite is a general-purpose implementation of this concept, and it's easy to create a Composite out of a Command:

public class CompositeMessageConsumer<T> : 
    private readonly IEnumerable<IMessageConsumer<T>> 
    public CompositeMessageConsumer(
        params IMessageConsumer<T>[] consumers)
        if (consumers == null)
            throw new ArgumentNullException("consumers");
        this.consumers = consumers;
    public IEnumerable<IMessageConsumer<T>> Consumers
        get { return this.consumers; }
    #region IMessageConsumer<T> Members
    public void Consume(T message)
        foreach (var consumer in this.Consumers)

The implementation of the Consume method simply loops over each composed IMessageConsumer<T> and invokes its Consume method.

I can, for example, implement a sequence of actions that will take place by composing the individual concrete implementations. First we have a guard that protects against invalid messages, followed by a consumer that writes the message to a persistent store, completed by a consumer that raises a Domain Event that the reservation request was accepted.

var c = new CompositeMessageConsumer<MakeReservationCommand>(

Consumers following the Liskov Substitution Principle will not notice the difference, as all they will see is an implementation of IMessageConsumer<MakeReservationCommand>.

More advanced programming constructs

The Composite pattern only describes a single, general way to compose implementations, but with a Command interface we can do more. As Domain-Driven Design explains, a successful interface is often characterized by making it possible to apply well-known arithmetic or logical operators. As an example, in the case of the IMessageConsumer<T> interface, we can easily mimic the well-known ?! ternary operator from C#:

public class ConditionalMessageConsumer<T> : 
    private Func<T, bool> condition;
    private IMessageConsumer<T> first;
    private IMessageConsumer<T> second;
    public ConditionalMessageConsumer(
        Func<T, bool> condition, 
        IMessageConsumer<T> first, 
        IMessageConsumer<T> second)
        if (condition == null)
            throw new ArgumentNullException("condition");
        if (first == null)
            throw new ArgumentNullException("first");
        if (second == null)
            throw new ArgumentNullException("second");
        this.condition = condition;
        this.first = first;
        this.second = second;
    public void Consume(T message)
        (this.condition(message) ? this.first : this.second)

This is more verbose than the ?! operator because C# doesn't allow us to define operator overloads for interfaces, but apart from that, it does exactly the same thing. Notice particularly that the Consume method uses the ?! operator to select among the two alternatives, and then subsequently invokes the Consume method on the selected consumer.

We can use the ConditionalMessageConsumer to define branches in the consumption of messages. As an example, we can encapsulate the previous CompositeMessageConsumer<MakeReservationCommand> into a conditional branch like this:

var consumer = 
    new ConditionalMessageConsumer<MakeReservationCommand>(
        guard.HasCapacity, c, rejectRaiser);

Notice that I use the method group syntax to supply the condition delegate. If the HasCapacity method returns true, the previous composite (c) is being invoked, but if the result is false we instead use a consumer that raises the Domain Event that the reservation request was rejected.

Concluding thoughts

Apart from the direct purpose of providing examples of the immensely powerful composition options a Command interface provides I want to point out a couple of things:

  • Each of the design pattern implementations (Null Object, Composite - even Conditional) are generic. This is a strong testament to the power of this particular abstraction.
  • The dynamic mocks I'm familiar with (Moq, Rhino Mocks) will by default try to create Null Object implementations for interfaces without explicit setups. Since it's trivial to implement a Null Command, they just emit them by default. If you use an AutoMocking Container with your unit tests, you can refactor to your heart's content, adding and removing dependencies as long as they are Command interfaces, and your testing infrastructure will just take care of things for you. It'll just work.
  • Did you notice that even with these few building blocks we have implemented a large part of a sequential workflow engine? We can execute consumers in sequence as well as branch between different sequences. Obviously, more building blocks are needed to make a full-blown workflow engine, but not that many. I'll leave the rest as an exercise to the reader :)

As I originally sketched, a Command interface is the ultimate in composability. To illustrate, the application from where I took the above examples is a small application with 48 types (classes and interfaces) in the production code base (that is, excluding unit tests). Of these, 9 are implementations of the IMessageConsumer<T> interface. If we also count the interface itself, it accounts for more than 20 percent of the code base. According to the Reused Abstractions Principle (RAP) I consider this a very successful abstraction.

Encapsulating AutoFixture Customizations

Friday, 18 March 2011 12:51:08 UTC

AutoFixture is designed around the 80-20 principle. If your code is well-designed I'd expect a default instance of Fixture to be able to create specimens of your classes without too much trouble. There are cases where AutoFixture needs extra help:

  • If a class consumes interfaces a default Fixture will not be able to create it. However, this is easily fixed through one of the AutoMocking Customizations.
  • If an API has circular references, Fixture might enter an infinite recursion, but you can easily customize it to cut off one the references.
  • Some constructors may only accept arguments that don't fit with the default specimens created by Fixture. There are ways to deal with that as well.

I could keep on listing examples, but let's keep it at that. The key assumption underlying AutoFixture is that these special cases are a relatively small part of the overall API you want to test - preferably much less than 20 percent.

Still, to address those special cases you'll need to customize a Fixture instance in some way, but you also want to keep your test code DRY.

As the popularity of AutoFixture grows, I'm getting more and more glimpses of how people address this challenge: Some derive from Fixture, others create extension methods or other static methods, while others again wrap creation of Fixture instances in Factories or Builders.

There really is no need to do that. AutoFixture has an idiomatic way to encapsulate Customizations. It's called… well… a Customization, which is just another way to say that there's an ICustomization interface that you can implement. This concept corresponds closely to the modularization APIs for several well-known DI Containers. Castle Windsor has Installers, StructureMap has Registries and Autofac has Modules.

The ICustomization interface is simple and has a very gentle learning curve:

public interface ICustomization
    void Customize(IFixture fixture);

Anything you can do with a Fixture instance you can also do with the IFixture instance passed to the Customize method, so this is the perfect place to encapsulate common Customizations to AutoFixture. Note that the AutoMocking extensions as well as several other optional behaviors for AutoFixture are already defined as Customizations.

Using a Customization is also easy:

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

You just need to invoke the Customize method on the Fixture. That's no more difficult than calling a custom Factory or extension method - particularly if you also use a Visual Studio Code Snippet.

When I start a new unit testing project, one of the first things I always do is to create a new ‘default' customization for that project. It usually doesn't take long before I need to tweak it a bit - if nothing else, then for adding the AutoMoqCustomization. To apply separation of concerns I encapsulate each Customization in its own class and compose them with a CompositeCustomization:

public class DomainCustomization : CompositeCustomization
    public DomainCustomization()
        : base(
            new AutoMoqCustomization(),
            new FuncCustomization())

Whenever I need to make sweeping changes to my Fixtures I can simply modify DomainCustomization or one of the Customizations it composes.

In fact, these days I rarely explicitly create new Fixture instances, but rather encapsulate them in a custom AutoDataAttribute like this:

public class AutoDomainDataAttribute : AutoDataAttribute
    public AutoDomainDataAttribute()
        : base(new Fixture()
            .Customize(new DomainCustomization()))

This means that I can reuse the DomainCustomization across normal, imperative unit tests as well as the declarative, data theories I normally prefer:

[Theory, AutoDomainData]
public void CanReserveReturnsTrueWhenQuantityIsEqualToRemaining(
    Capacity sut, Guid id)
    var result = sut.CanReserve(sut.Remaining, id);

Using Customizations to encapsulate your own specializations makes it easy to compose and manage them in an object-oriented fashion.

Resolving closed types with MEF

Monday, 14 March 2011 20:49:11 UTC

A while back I posed the challenge of resolving closed types with MEF. I received some responses, but I also wanted to provide an alternative outline for a solution. In case you don't remember the problem statement, it revolved around using the Managed Extensibility Framework (MEF) to compose classes in those cases where it's impossible to annotate those classes with the MEF attributes. In the given example I want to compose the Mayonnaise class from EggYolk and OliveOil, but all three classes are sealed and cannot be recompiled.

As I describe in my book, a general solution to this type of problem is to create a sort of adapter the exports the closed type via a read-only attribute, like these EggYolkAdapter and MayonnaiseAdapter classes (the OliveOilAdapter looks just like the EggYolkAdapter):

public class EggYolkAdapter
    private readonly EggYolk eggYolk;
    public EggYolkAdapter()
        this.eggYolk = new EggYolk();
    public virtual EggYolk EggYolk
        get { return this.eggYolk; }
public class MayonnaiseAdapter
    private readonly Mayonnaise mayo;
    public MayonnaiseAdapter(
        EggYolk yolk, OliveOil oil)
        if (yolk == null)
            throw new ArgumentNullException("yolk");
        if (oil == null)
            throw new ArgumentNullException("oil");
        this.mayo = new Mayonnaise(yolk, oil);
    public virtual Mayonnaise Mayonnaise
        get { return this.mayo; }

Doing it like this is always possible, but if you have a lot of types that you need to compose, it becomes tedious having to define a lot of similar adapters. Fortunately, we can take it a step further and generalize the idea of a MEF adapter to a small set of generic classes.

The EggYolkAdapter can be generalized as follows:

public class MefAdapter<T> where T : new()
    private readonly T export;
    public MefAdapter()
        this.export = new T();
    public virtual T Export
        get { return this.export; }

Notice that I've more or less just replaced the EggYolk class with a type argument (T). However, I also had to add the generic new() constraint, which is often quite restrictive. However, to support a type like Mayonnaise, I can create another, similar generic MEF adapter like this:

public class MefAdapter<T1, T2, TResult>
    private readonly static Func<T1, T2, TResult> createExport =
        FuncFactory.Create<T1, T2, TResult>();
    private readonly TResult export;
    public MefAdapter(T1 arg1, T2 arg2)
        this.export = createExport(arg1, arg2);
    public virtual TResult Export
        get { return this.export; }

The major difference from the simple MefAdapter<T> is that we need slightly more complicated code to invoke the constructor of TResult, which is expected to take two constructor arguments of types T1 and T2. This work is delegated to a FuncFactory that builds and compiles the appropriate delegate using an expression tree:

internal static Func<T1, T2, TResult>
    Create<T1, T2, TResult>()
    var arg1Exp =
        Expression.Parameter(typeof(T1), "arg1");
    var arg2Exp = 
        Expression.Parameter(typeof(T2), "arg2");
    var ctorInfo = 
    var ctorExp =
        Expression.New(ctorInfo, arg1Exp, arg2Exp);
    return Expression.Lambda<Func<T1, T2, TResult>>(
        ctorExp, arg1Exp, arg2Exp).Compile();

With a couple of MEF adapters, I can now compose a MEF Catalog almost like I can with a real DI Container, and resolve the Mayonnaise class:

var catalog = new TypeCatalog(
    typeof(MefAdapter<EggYolk, OliveOil, Mayonnaise>)
var container = new CompositionContainer(catalog);
var mayo = container.GetExportedValue<Mayonnaise>();

If you want to change the Creation Policy to NonShared, you can derive from the MefAdapter classes and annotate them with [PartCreationPolicy] attributes.

I'd never voluntarily choose to use MEF like this, but if I was stuck with MEF in a project and had to use it like a DI Container, I'd do something like this.


Is there anyway we can enhance your MefAdapter to support keys as well? So that when the adapter is export's using the Export property we could associate a key to the export? With attributes I know the string has to be constant, didn't know if we could somehow assign this in runtime even though.
2012-09-19 23:12 UTC

Page 24 of 36

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