我正在编写一个组件，给定一个ZIP文件，需要：

1. 解压缩文件。
2. 在解压缩的文件中找到一个特定的dll。
3. 通过反射加载该dll，并在其上调用一个方法。

我想单元测试这个组件。

我很想编写直接处理文件系统的代码：

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

但人们经常说，“不要编写依赖于文件系统，数据库，网络等的单元测试”

如果我以单元测试友好的方式编写它，我想这应该是这样的：

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

好极了！现在它是可测试的; 我可以将测试双打（嘲笑）喂给DoIt方法。但费用是多少？我现在必须定义3个新接口来制作这个测试。我究竟在测试什么？我正在测试我的DoIt函数是否正确地与它的依赖进行交互。它不测试zip文件是否正确解压缩等。

它不觉得我正在测试功能了。这感觉就像我只是测试课堂互动。