1
这可能是疯狂的。传递系统类作为构造函数参数
我想把依赖注入的想法变为极端。我已将所有与System.IO有关的行为隔离到一个类中，以便我可以在其他类中嘲笑该类，从而减轻我的更大的单元测试套件对担心实际文件系统的负担。
但文件IO类我最终只能与集成测试，测试which-- course--的增加了复杂性我真的不希望处理当所有我真正想要做的就是确保我的FileIO类调用正确的System.IO东西。我不需要集成测试System.IO。我的FileIO类不仅仅是简单地包装System.IO函数，现在它每次都包含一些逻辑（也许这就是问题所在）。
所以我想是能够测试我的文件IO类，以确保它使通过嘲讽System.IO类本身正确的系统调用。理想情况下，这将是那么容易，因为有像这样一个构造函数：
public FileIO(
System.IO.Directory directory,
System.IO.File file,
System.IO.FileStream fileStream
)
{
this.Directory = directory;
this.File = file;
this.FileStream = fileStream;
}
然后在类似的方法调用：
public GetFilesInFolder(string folderPath)
{
return this.Directory.GetFiles(folderPath)
}
但这个因为有关System.IO类不飞是静态的类。据我所知，它们既不能以这种方式实例化，也不能为了嘲弄而被分类。