TDD with MS Fakes

Question

I'm going to try TDD and I'm researching right tools for that. At work we are using MS Fakes so it would be fine not to change it and use MS Fakes with TDD. But I have one serious problem. It seems to me that MS Fakes are intended to use in scenario: write code -> write unit test for it. How can I mock some interface during TDD with MS Fakes?

For example I have following code in one file (refactoring will be done later)

[TestClass]
public class MyTests
{
    [TestMethod]
    public void ShouldReturnSomeResultIfEmptyCollectionOfCustomersWasReturned()
    {
        // arrange
        ICustomerRepository customerRepository = null;
        var targetService = new MyTargetService(customerRepository);

        // act
        int result = targetService.MyMethod();

        // assert
        Assert.AreEqual(1, result);

    }
}

public class MyTargetService : IMyTargetService
{
    private readonly ICustomerRepository customerRepository;

    public MyTargetService(ICustomerRepository customerRepository)
    {
        this.customerRepository = customerRepository;
    }

    public int MyMethod()
    {
        if (customerRepository.GetCustomers().Any())
        {
            return 0;
        }

        return 1;
    }
}

public interface IMyTargetService
{
}

public interface ICustomerRepository
{
    Customer[] GetCustomers();
}

public class Customer
{
}

During my TDD process I've put everything in one file and then will refactor this and move to different assemblies. But I need to mock inline in this place ICustomerRepository customerRepository = null;. I can do it easy with NSubstitute for example. But if I use MS Fakes I need first to move this interface to another project, reference this project from one where unit test is situated and press "Add Fake Assembly". This seems very complicated workflow which makes TDD not so quick and efficient. I want to have code like this just in place without all those strange manipulations:

ICustomerRepository customerRepository = new StubBase<ICustomerRepository>
                {
                    GetCustomers = () => Enumerable.Empty<Customer>().ToArray(),
                };

But StubBase<> is abstract. So is there any way to do such thing with MS Fakes or no?

Answer 1

Fakes relies on build-time code generation and currently requires you to define the interfaces/classes you want to stub in a separate project. Compared to other frameworks that generate stubs at run time, such as NSubstitute, this requires one additional refactoring step before you can compile a new test - moving the new interface you just created from the test project to the target project. This refactoring can be accomplished in just a few keystrokes with Resharper.

Answer 2

At the risk of starting a flame war, this has been true for most testing tools from the MS suite. Short answer: When using these tools, you should make an informed decision on whether you want to use them. If you choose yes, you have to abide by MS's definition of TDD or unit-testing in general - even if it appears to be counterintuitive.

• Coded UI requires you to generate a map of your UI before you start writing tests. This mandates that the UI is complete before you can begin scripting tests.
• MSTest forces you to write tests that can't share (expensive to create) state even if they belong to the same test fixture. This means expensive setup has to be run over and over again to keep the tests independent / parallel-friendly.
• With PEX, MS promised test coverage for already written code.. by auto-generating test cases. It is however in no way related to TDD.

MS Fakes seems to dictate that you need to right click the assembly containing your interfaces and generate a Fakes assembly. Then learn the naming conventions (which seem a bit weird to me) and map lambda expressions or delegates to each interface member that maybe exercised by your code. I'm wary of the resultant tests not being readable / refactoring friendly.

For the recommended case where you have your dependencies behind an abstraction layer (interface), the usual suspects like Rhino, Moq, NSubstitute work fine without getting in your way. The only place I find for MS Fakes is with legacy code or third party code, where you don't have access to the source to decouple/inject dependencies. In such cases, MS Fakes might prove useful.

Answer 3

I do not recommend using MS Fakes. It'll get in your way and cause you to code awful tests and it forces you to use xml files. It's just not a good test framework period for TDD. Roy Osherove will vouch for that, he did in his books.

Keep things simple right? MS Fakes will cause you and require you to do the opposite and you'll end up with a mess if you use that tool.