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");
        }
 
        this.foo = foo;
    }
 
    public IFoo Foo
    {
        get { return this.foo; }
    }
}

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();
fixture.Register<IFoo>(
    fixture.CreateAnonymous<DummyFoo>);
var b = fixture.CreateAnonymous<Bastard>();
Assert.IsAssignableFrom<DefaultFoo>(b.Foo);

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())));
fixture.Register<IFoo>(
    fixture.CreateAnonymous<DummyFoo>);
var b = fixture.CreateAnonymous<Bastard>();
Assert.IsAssignableFrom<DummyFoo>(b.Foo);

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();
fixture.Customizations.Add(
    new MethodInvoker(
        new GreedyConstructorQuery()));
fixture.Register<IFoo>(
    fixture.CreateAnonymous<DummyFoo>);
var b = fixture.CreateAnonymous<Bastard>();
Assert.IsAssignableFrom<DummyFoo>(b.Foo);

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.


Comments

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;
  5.  
  6. using Xunit;
  7.  
  8. public class JustATest {
  9.  
  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());
  17.  
  18. var foo = fixture.Create<Foo>();
  19. Assert.NotNull(foo.myStr);
  20. }
  21. }
  22.  
  23. public class Foo {
  24. public Foo(string myStr) {
  25. this.myStr = myStr;
  26. }
  27.  
  28. public Foo() {
  29. }
  30.  
  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


Wish to comment?

You can add a comment to this post by sending me a pull request. Alternatively, you can discuss this post on Twitter or Google Plus, or somewhere else with a permalink. Ping me with the link, and I may add it as a comment.

Published

Tuesday, 19 April 2011 06:59:19 UTC

Tags



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