Question

I am writing a component that, given a ZIP file, needs to:

1. Unzip the file.
2. Find a specific dll among the unzipped files.
3. Load that dll through reflection and invoke a method on it.

I’d like to unit test this component.

I’m tempted to write code that deals directly with the file system:

void DoIt() {    Zip.Unzip(theZipFile, 'C:\\foo\\Unzipped');    System.IO.File myDll = File.Open('C:\\foo\\Unzipped\\SuperSecret.bar');    myDll.InvokeSomeSpecialMethod(); } 

But folks often say, ‘Don’t write unit tests that rely on the file system, database, network, etc.’

If I were to write this in a unit-test friendly way, I suppose it would look like this:

void DoIt(IZipper zipper, IFileSystem fileSystem, IDllRunner runner) {    string path = zipper.Unzip(theZipFile);    IFakeFile file = fileSystem.Open(path);    runner.Run(file); } 

Yay! Now it’s testable; I can feed in test doubles (mocks) to the DoIt method. But at what cost? I’ve now had to define 3 new interfaces just to make this testable. And what, exactly, am I testing? I’m testing that my DoIt function properly interacts with its dependencies. It doesn’t test that the zip file was unzipped properly, etc.

It doesn’t feel like I’m testing functionality anymore. It feels like I’m just testing class interactions.

My question is this: what’s the proper way to unit test something that is dependent on the file system?

edit I’m using .NET, but the concept could apply Java or native code too.

Answer 1

There’s really nothing wrong with this, it’s just a question of whether you call it a unit test or an integration test. You just have to make sure that if you do interact with the file system, there are no unintended side effects. Specifically, make sure that you clean up after youself — delete any temporary files you created — and that you don’t accidentally overwrite an existing file that happened to have the same filename as a temporary file you were using. Always use relative paths and not absolute paths.

It would also be a good idea to chdir() into a temporary directory before running your test, and chdir() back afterwards.