Should I mock out framework classes

I'm writing a green field project using C# and the .NET framework 4 and since my last application was dogged with a lack of tests and not a very testable design I'm determined to avoid making the same mistake this time.

I've got external dependencies for every class in interfaces that are injected into the class and now I'm writing the concrete implementations. While I'm not about to start writing unit tests to test code in the framework I am concerned that if there's a bug in the way I call a framework class then I've got no way of testing it. As a very simple example lets say I was using a SQLCommand (I'm actually using EF 4.1 but this is just an example) and I forgot to set the connection property on the command. My idea is that if I mocked out certain framework classes I could test these conventions with mocking and avoid a potential source of bugs. Doing this would also mean that I simulate certain exceptions from framework classes that are awkward to test for b开发者_运维百科ut do occur e.g. UnauthorizedAccessException, OutOfMemoryException etc.

I realise that the code would likely just break when I tried to run the code to test it but there's something in the back of my mind telling me there's still a chance I could miss something and only find out about it once the product is out in the field. Is there any justification for doing this or is this a rather severe case of YAGNI?

Creating concrete mocks of Injected Interfaces is going too far. You shouldn't need to emulate the entire framework. You should however be checking your code paths and ensuring that you handle exceptions and invalid inputs correctly.

Most mocking frameworks such as Rhino Mocks allows you to simulate throwing exceptions from injected mock objects.

[Test]
public void testThrowsExceptions()
{
    // Arrange
    var dependency1 = MockRepository.Mock<IMockFrameworkObject1>();
    var dependency2 = MockRepository.Mock<IMockFrameworkObject2>();

    dependency2.Expect(d2 => d2.SomeAction).Throws(new someexception);

    var myObject = new ConcreteObject(dependency1, dependency2);

    // Act
    myObject.SomeAction();

    // Assert
}

I see considerable value in mocking classes so that hard-to-stimulate errors can be introduced and hence your error paths properly tested.

I don't see how mocking the framework can catch the "forgot to set xxx" error. Your Mock would need to "know" that the framework expects setConnection() to be called before findThing(), to catch those errors you'd need to emulate the entirety of the Framework.

I think you need to look at Unit testing - exercise your own code paths - which can benefit from using Mocks and Integration testing which tests the interaction of different components, like your code with the framework.

You may well use the same test drivers in both cases (I'm Java, so JUnit for me) but the test strategy is different. Be clear which kind of testing you are doing.

You can use Moles to simulate framework method calls. Here is how it used for a database: Use Mole to unit test SQLDataReader