Including resources file for Unit test in C# project

I have some functions that read and modify files. In order to make the unit tests independent of any file system issues, I want to include the files inside the project.

However, my function should be getting the filePath, and all I can get from the assembly is a FileStream. Any idea how I can开发者_开发技巧 get the file path of a resource file in the project?

System.Reflection.Assembly a = System.Reflection.Assembly.Load(assemblyName);
FileStream stream = a.GetFile(assemblyName + "." + fileName);

My usual solution for this problem is that I refactor my program to open the file in the calling method and then pass a Stream instead of passing the filename and opening the file there.

For testing, this allows me to pass a MemoryStream so I can write my unit test without using the file system at all. It's sometimes even easier to check if the data has been written correctly and it's definitely faster, especially for a higher number of tests. You just have to remember to flush the MemoryStream after writing as .NET doesn't always do this automatically.

Example from one of my programs:

public TestSaveAndLoad()
{
  [... create data to save ...]
  using (MemoryStream targetStream = new MemoryStream())
  {
    target.Save(targetStream);
    targetStream.Flush();
    targetStream.Seek(0, ...);
    target.Load(targetStream);
  }
  [... assert that the loaded data equals the saved data ...]
}

An embedded resource doesn't exist on the file system, so it doesn't have any file path.

You have two options:

• Change the API of your SUT so that it accepts a Stream instead of only a file path. This solution is much preferred.
• Save the embedded resource to a temporary file during unit testing, making sure to delete it again after each test case.

The first solution is an excellent example of how TDD drives us towards better, more flexible APIs.

You could set the data files to be copied to the bin directory when the project is built, then reference them via Directory.GetCurrentDirectory() in your test. Or even leave them where they are and simply use a relative path based on the current directory.

Better, though, would be to restructure your code to rely the Stream class, then use a combination of mocking and dependency injection to supply a mock stream with the data -- or use a memory stream, if faking works better.

If you set the file's build action to copy, you can then predict where the file should be (probably a bunch of .. \ .. \ .. \ 's but still). I'm guessing you have an input on your method for file name, so that should work just fine.

Just as a suggestion, is it possible to abstract out the actual reading/change of that file into a method and pass a string value? The only reason why I bring that up is that it smells like an integration test (touching the file system).