How do you mock out the file system in C# for unit testing?

Question

Are there any libraries or methods to mock out the file system in C# to write unit tests? In my current case I have methods that check whether certain file exists and read the creation date. I may need more than that in future.

Armorial

This looks like a duplicate of several others, including: #664777. – Sunstone

Maybe try looking into pex (research.microsoft.com/en-us/projects/pex/filesystem.pdf) – Rachellrachelle

@Mitch: Most of the time, it is sufficient to place data in the file system and let unit tests run their course. However, I've encountered methods that execute many IO operations, and setting up the test environment for such methods is greatly simplified by using a mock file system. – Aristippus

I wrote github.com/guillaume86/VirtualPath for that purpose (and more), it's still WIP and the API will certainly change but it already works, and some tests are included. – Juggernaut

Answer 1

Edit: Install the NuGet package System.IO.Abstractions.

This package did not exist when this answer was originally accepted. The original answer is provided for historical context below:

You could do it by creating an interface:

interface IFileSystem {
    bool FileExists(string fileName);
    DateTime GetCreationDate(string fileName);
}

and creating a 'real' implementation which uses System.IO.File.Exists() etc. You can then mock this interface using a mocking framework; I recommend Moq.

Edit: somebody's done this and kindly posted it online here.

I've used this approach to mock out DateTime.UtcNow in an IClock interface (really really useful for our testing to be able to control the flow of time!), and more traditionally, an ISqlDataAccess interface.

Another approach might be to use TypeMock, this allows you to intercept calls to classes and stub them out. This does however cost money, and would need to be installed on your whole team's PCs and your build server in order to run, also, it apparently won't work for the System.IO.File, as it can't stub mscorlib.

You could also just accept that certain methods are not unit testable and test them in a separate slow-running integration/system tests suite.

Breaker

In my opinion, creating an interface as Matt describes here is the way to go. I've even written a tool that generates such interfaces for you, which is useful when trying to mock static and/or sealed classes, or methods that are non-deterministic (i.e. clocks and random number generators). See jolt.codeplex.com for more information. – Aristippus

Looks like the repo in the referenced article has been deleted/moved without notice. However, there appears to be a nuget package of its efforts here: nuget.org/packages/mscorlib-mock – Consternate

Typemock does have restrictions on what types are fakeable but (at least in the current version as of Oct 2017) you can definitely fake the File static class. I just verified this myself. – Scott

Can you sum up some integration test suites? – Alyssaalyssum

Answer 2

This imaginary library exists now, there is a NuGet package for System.IO.Abstractions, which abstracts away the System.IO namespace.

There is also a set of test helpers, System.IO.Abstractions.TestingHelpers which - at the time of writing - is only partially implemented, but is a very good starting point.

Amal

I think that standardizing around this already built abstraction is the best bet. Never heard of that library, so thanks a lot for the heads up. – Walz

PM stands for package manager.. to open... Tools > NuGet Package Manager > Package Manager Console – Wilona

Install TestableIO.System.IO.Abstractions and TestableIO.System.IO.Abstractions.Wrappers into your main project. And TestableIO.System.IO.Abstractions.TestingHelpers into your test project! The ...Wrappers is needed to get the default implementation of IFileSystem with new System.IO.Abstractions.FileSystem() – Colchis

Answer 3

You're probably going to have to build a contract to define what things you need from the file system and then write a wrapper around those functionalities. At that point you'd be able to mock or stub out the implementation.

Example:

interface IFileWrapper { bool Exists(String filePath); }

class FileWrapper: IFileWrapper
{
    bool Exists(String filePath) { return File.Exists(filePath); }        
}

class FileWrapperStub: IFileWrapper
{
    bool Exists(String filePath) 
    { return (filePath == @"C:\myfilerocks.txt"); }
}

Metamorphosis

Answer 4

By using System.IO.Abstractions and System.IO.Abstractions.TestingHelpers like that:

public class ManageFile {
   private readonly IFileSystem _fileSystem;
   public ManageFile(IFileSystem fileSystem){

      _fileSystem = fileSystem;
   }

   public bool FileExists(string filePath){}
       if(_fileSystem.File.Exists(filePath){
          return true;
       }
       return false;
   }
}

In your Test Class, you use MockFileSystem() to mock file and you instanciate ManageFile like:

var mockFileSysteme = new MockFileSystem();
var mockFileData = new MockFileData("File content");
mockFileSysteme.AddFile(mockFilePath, mockFileData );
var manageFile = new ManageFile(mockFileSysteme);

Cornuted

Answer 5

My recommendation is to use http://systemwrapper.codeplex.com/ as it provides wrappers for mostly used types in System namespace

Prolific

I'm currently using this library, and now that I've discovered that its abstractions for things like FileStream don't include IDisposable, I'm looking for a replacement. If the library doesn't allow me to properly dispose of streams, then I can't recommend (or use) it for handling those kinds of operations. – Padraic

SystemWrapper's IFileStreamWrap implements IDisposable now. – Wendy

systemwrapper is .net framework only, it will cause weird issues if used with .netcore – Hardman

Answer 6

I've come across the following solutions to this:

• Write Integration tests, not unit tests. For this to work you need a simple way of creating a folder where you can dump stuff without worrying about other tests interfering. I have a simple TestFolder class which can create a unique per test method folder to use.
• Write a mockable System.IO.File. That is create a IFile.cs. I find using this often ends up with tests that simply prove you can write mocking statements, but do use it when the IO usage is small.
• Examine you layer of abstraction, and extract the file IO from the class. The create a interface for this. The remainder use integration tests (but this will be very small). This differs from above in that instead of doing file.Read you write the intent, say ioThingie.loadSettings()
• System.IO.Abstractions. I've not used this yet, but it is the one I'm most excited about playing with.

I end up using all the methods above, depending on what I'm writing. But most of the time I end up thinking abstraction is wrong when I write unit tests that hit the IO.

Lair

Link to IFile.cs is broken. – Consternate

Answer 7

You can do that using Microsoft Fakes without the need to change your codebase for example because it was frozen already.

First generate a fake assembly for System.dll - or any other package and then mock expected returns as in:

using Microsoft.QualityTools.Testing.Fakes;
...
using (ShimsContext.Create())
{
     System.IO.Fakes.ShimFile.ExistsString = (p) => true;
     System.IO.Fakes.ShimFile.ReadAllTextString = (p) => "your file content";

      //Your methods to test
}

Rehabilitate

Answer 8

I'm not sure how you would mock up the file system. What you could do is write a test fixture setup that creates a folder, etc. with the necessary structure for the tests. A teardown method would clean it up after the tests run.

Edited to add: In thinking about this a little more, I don't think you want to mock the file system to test this type of methods. If you mock the file system to return true if a certain file exists and use that in your test of a method that checks if that file exists, then you're not testing much of anything. Where mocking the file system would be useful is if you wanted to test a method that had a dependency on the file system but the file system activity was not integral to the method under test.

Neoterism

Answer 9

It would be difficult to mock the file system in a test since the .NET file APIs are not really based on interfaces or extensible classes that could be mocked.

However, if you have your own functional layer to access the file system, you could mock that in a unit test.

As an alternative to mocking, consider just creating the folders and files you need as part of your test setup, and deleting them in your teardown method.

Carbonous

Answer 10

To answer your specific question: No, there are no libraries that will allow you to mock file I/O calls (that I know of). This means that "properly" unit testing your types will require that you take this restriction into consideration when you define your types.

Quick side note about how I define a "proper" unit test. I believe that unit tests should confirm that you get the expected output (be that an exception, call on a method, etc) provided known inputs. This allows you to set up your unit test conditions as a set of inputs and/or input states. The best way I've found to do this is using interface-based services and dependency injection so that each responsibility external to a type is provided via an interface passed via a constructor or property.

So, with this in mind, back to your question. I've mocked file system calls by creating a IFileSystemService interface along with a FileSystemService implementation that is simply a facade over the mscorlib file system methods. My code then uses the IFileSystemService rather than the mscorlib types. This allows me to plug in my standard FileSystemService when the application is running or mock the IFileSystemService in my unit tests. The application code is same regardless of how it's run, but the underlying infrastructure allows that code to be easily tested.

I'll acknowledge that it's a pain to use the wrapper around the mscorlib file system objects but, in these specific scenarios, it's worth the extra work as the testing becomes so much easier and more reliable.

Diclinous

Answer 11

Creating an interface and mocking it for testing is the cleanest way to go. However, as an alternative yo could take a look at the Microsoft Moles framework.

Homeopathic

Answer 12

Common solution is using some abstract filesystem API (like Apache Commons VFS for Java ): all application logic uses API and unit test is able to mock real filesystem with stub implementation (in-memory emulation or something like that).

For C# the similar API exists: NI.Vfs which is very similar to Apache VFS V1. It contains default implementations both for local filesystem and in-memory filesystem (last one can be used in unit tests from the box).

Falcongentle

Answer 13

We currently use a proprietary data engine and its API is not exposed as interfaces so we can hardly unit test our data access code. Then I went with Matt and Joseph's approach too.

Vadose

Answer 14

I would go with Jamie Ide's response. Don't try to mock out things that you didn't write. There will be all manner of dependancies you didn't know about - sealed classes, non virtual methods etc.

Another approach would be to wrap the appopiate methods with something that is mockable. e.g. create a class called FileWrapper that allows access to the File methods but is something you can mock out.

Bordie