TDD System Under Test Creation Patterns (AutoFixture) - tdd

Question

I'm trying to use SUT Factory 'pattern' to create my SUT.
Given the SUT structure:
namespace MySut
{
public class Dep1
{
}
public class Dep2
{
}
public class Sut
{
public Sut( Dep1 dep1, Dep2 dep2 )
{
}
}
}
I'm using AutoFixture, and am wondering what's the best way to collapse the following Specifications and associated SUT factory method [valuable but]busywork:
namespace MySpecifications
{
using MySut;
public class MySpecification
{
public void TestCore()
{
// Dont care about dependencies, testing core functionality
var sut = CreateSut();
}
public void TestDep1Interaction()
{
// Dont care about Dep2, want to observe stuff on the Dep1 dependent object
var sut = CreateSut( new Mock<Dep1>().Object );
}
public void TestDep2Interaction()
{
// Dont care about Dep1, want to observe stuff on the Dep2 dependent object
var sut = CreateSut( new Mock<Dep2>().Object );
}
private object CreateSut( )
{
return CreateSut( CreateDep1(), CreateDep2() );
}
private object CreateSut( Dep1 dep1 )
{
return CreateSut( dep1, CreateDep2() );
}
private object CreateSut( Dep2 dep2 )
{
return CreateSut( CreateDep1(), dep2 );
}
private Sut CreateSut( Dep1 dep1, Dep2 dep2 )
{
return new Sut( dep1, dep2 );
}
private static Dep1 CreateDep1()
{
return new Fixture().CreateAnonymous<Dep1>();
}
private static Dep2 CreateDep2()
{
return new Fixture().CreateAnonymous<Dep2>();
}
}
}
to something like:
public class MyAutoFixturedSpecification
{
public void TestCore()
{
// Dont care about dependencies, testing core functionality
var sut = CreateSut();
}
public void TestDep1Interaction()
{
// Dont care about Dep2, want to observe stuff on the Dep1 dependent object
var sut = CreateSut( new Mock<Dep1>().Object );
}
public void TestDep2Interaction()
{
// Dont care about Dep1, want to observe stuff on the Dep2 dependent object
var sut = CreateSut( new Mock<Dep2>().Object );
}
private object CreateSut( params object[] injectedNonAnonymouses )
{
return new Fixture( ).Build<Sut>( )./*??????*/;
}
}
or:
public class MyAnticipatedAutoFixturedSpecification
{
public void TestCore()
{
// Dont care about dependencies, testing core functionality
var sut = new Fixture( ).Build<Sut>().CreateAnonymous( );
}
public void TestDep1Interaction()
{
// Dont care about Dep2, want to observe stuff on the Dep1 dependent object
var sut = new Fixture().Build<Sut>()/*.With( new Mock<Dep1>().Object )*/.CreateAnonymous();
}
public void TestDep2Interaction()
{
// Dont care about Dep1, want to observe stuff on the Dep2 dependent object
var sut = new Fixture().Build<Sut>()/*.With( new Mock<Dep2>().Object )*/.CreateAnonymous();
}
}
i.e., removing all the factory junk, so that my specifications can easily cope with a transition to:
namespace MySutWithNewDependency
{
public class Dep1
{
}
public class Dep2
{
}
public class Dep3
{
}
public class Sut
{
public Sut( Dep1 dep1, Dep2 dep2, Dep3 dep3 )
{
}
}
}
While there is overlap with the notion of an automocking container, I'm still not looking for a golden hammer - just a way to be able to mock 0 or 1 thing at a time and yet be able to customise creation of dependent objects without having to revisit explicit calls to the Sut constructor whenever its' set of dependencies changes.
(Also using xUnit.net (SubSpec style), Moq, Ninject2 (though dont want to use DI in my specifications))

Answer 1

AutoFixture can more or less do all of this for you without all that extra scaffolding. I'd start out with a basic Fixture and use it to resolve Sut:
var fixture = new Fixture();
var sut = fixture.CreateAnonymous<Sut>();
This assumes that Dep1 and Dep2 can be created automatically by AutoFixture, but as presented, they can because they have default constructors.
When you want to override a specific type, you can use the Register method like this:
var fixture = new Fixture();
var mock = new Mock<Dep1>();
fixture.Register(mock.Object);
// Setup mock if necessary...
var sut = fixture.CreateAnonymous<Sut>();
This will cause fixture to use mock.Object any time Dep1 is needed, including when the Sut constructor is invoked. This definitely fits your requirement of being robust in the face of evolving constructors, and one of the main reasons AutoFixture was built like that.
In a more realistic scenario, Dep1 and Dep2 might be interfaces, in which case you might want to Register them as part of a 'default Fixture'. This is certainly also possibly because that last call to Register wins. This means that you can configure a Fixture instance with some good defaults and still be able to override specific types whenever you need to do this.
I personally use AutoFixture as an auto-mocking container. This discussion provides a hint at how this would be possible with the AutoFixture 1.1 API, but the new kernel for AutoFixture 2.0 will provide much better extensibility options. When I get to it, I will write a blog post on this subject.
P.S. Sorry about the late reply, but I didn't see your question before now. In the future, feel free to ping me (e.g. on Twitter) for a faster reply.