This is probably crazy.

I want to take the idea of Dependency Injection to extremes. I have isolated all System.IO-related behavior into a single class so that I can mock that class in my other classes and thereby relieve my larger suite of unit tests of the burden of worrying about the actual file system.

But the File IO class I end up with can only be tested with integration tests, which-- of course-- introduces complexity I don't really want to deal with when all I really want to do is make sure my FileIO class calls the correct System.IO stuff. I don't need to integration test System.IO. My FileIO class is doing more than simply wrapping System.IO functions, every now and then it does contain some logic (maybe this is the problem?).

So what I'd like is to be able to test my File IO class to ensure that it makes the correct system calls by mocking the System.IO classes themselves. Ideally this would be as easy as having a constructor like so:

    public FileIO(
        System.IO.Directory directory, 
        System.IO.File file, 
        System.IO.FileStream fileStream
    )
    {
        this.Directory = directory;
        this.File = file;
        this.FileStream = fileStream;
    }

And then calling in methods like:

    public GetFilesInFolder(string folderPath)
    {
        return this.Directory.GetFiles(folderPath)
    }

But this doesn't fly since the System.IO classes in question are static classes. As far as I can tell they can neither be instantiated in this way or subclassed for the purposes of mocking.