views:

49

answers:

4

I have some functions that read & modify files. In order to make the unit tests independant 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);

Thanks!

A: 

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

jeriley
+1  A: 

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.

Mark Seemann
I started with Stream s all around , but I felt like I'm juggling to much open handlers in the air. I'd give it a second thought , though. Thanks.
yossale
You can always create overloaded methods: one that takes a file path, but really just delegates to the other that takes a Stream...
Mark Seemann
+1  A: 

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.

tvanfosson
+1  A: 

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 filesystem at all. It's sometimes even easier to check if the data has been written correctly and it's definatly 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 ...]
}
dbemerlin
Cool . I didn't like all those streams running around , and this looks like a good solution.
yossale