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 but 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.