How do I (or do I) unit test a concrete dependency

I have a business layer class that uses System.IO.File to read information from various files. In order to unit test this class I've chosen to replace the dependency on the File class with an injected dependency like so:

using System.IO;

public interface IFileWrapper
{
    bool FileExists( string pathToFile );
    Stream Open( string pathToFile );
}

Now I can test my class using a Mock and all is right with the world. Separately, I need a concrete implementation. I have the following:

using System;
using System.IO;

public class FileWrapper : IFileWrapper
{
    public bool FileExists( string pathToFile )
    {
        return File.Exists( pathToFile );
    }

    public Stream Open( string pathToFile )
    {
        return File.Open( pathToFile, FileMode.Open, FileAccess.Read, FileShare.Read );
    }
}

Now my business class is no longer dependent on the System.IO.File class and can be tested using a Mock of IFileWrapper. I see no need to test the System.IO.File class as I assume this has been thoroughly tested by Microsoft and proven in countless uses.

How do I test the concrete FileWrapper class? Though this is a simple class (low risk), I have larger examples that follow the same approach. I cannot approach 100% code coverage (assuming this is important) wit开发者_Python百科hout completing this.

The larger question here I suppose is, how to bridge the gap between unit testing and integration testing? Is it necessary to test this class, or is there some attribute to decorate this class to exlcude this from code coverage calculation.

As a rule of thumb you should unit test all production code you write. However, due to the nature of how .NET is designed, there will always be classes like your Adapter class above that can't be properly unit tested.

My personal rule of thumb is that if you can reduce each member in the Adapter to a cyclomatic complexity of 1 it's okay to declare it a Humble Object.

AFAIK there are no ways to exclude code from coverage reports, but you can implement your Humble Objects in separate assemblies which are exempt from coverage reporting.

In your case testing FileWrapper is an overhead. It has no any role except of being a wrapper. So I would go with attribute that is excluding it from coverage calculation.

In other cases you can have some additional logic in such kind of types like FileWrapper and in those cases Integration Testing could help you.

The larger question here I suppose is, how to bridge the gap between unit testing and integration testing?

In general you should use this two kinds of testing separately. Integration testing should be on the higher level, testing integration between two components, so if you feel that you need to test this dependency - go on, in other case don't write such kind of tests. Integration tests always more complex, much longer to run and more hard to maintain than unit testing, so you should think twice before writing each integration test. Thats why I wouldn't say that if you will write some tests for FileWrapper this will be an Integration Test. So my point is that there is no gap between unit and integration testing, they are solving different problems.

The sole purpose of your adapter class is to wrap the filesystem. Therefore, you can make one unit test that checks this behaviour is correct. Having satisifed yourself the wrapper works correctly, you can then comfortably use a test double in it's place everywhere else.

Your unit test should be very simple, but must use the concrete implementation. This means it will probably be relatively slow (> 5ms) and somewhat annoying to setup/teardown. My definition of a unit test is one that runs relatively quickly and tests a small amount of code, in this case, one class.

You must then be very careful not to put any additional logic in the class, or that logic will too require a difficult unit test.

The second approach is to cover this in an integration test or manual testing. If this class is used everywhere, you will catch any errors there quickly. Since there is little complexity to this class, the risk of introducing errors is low.