这可能很疯狂.
我想把依赖注入的想法变为极端.我已将所有与System.IO相关的行为隔离到一个类中,这样我就可以在其他类中模拟该类,从而减轻了我对更大的单元测试套件担心实际文件系统的负担.
但是我最终得到的File IO类只能通过集成测试进行测试,当然,当我真正想要做的就是确保我的FileIO类调用时,它会引入我真正不想处理的复杂性.正确的System.IO东西.我不需要集成测试System.IO.我的FileIO类不仅仅是简单地包装System.IO函数,它不时地包含一些逻辑(也许这就是问题?).
所以我想要的是能够测试我的File 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;
}
Run Code Online (Sandbox Code Playgroud)
然后调用以下方法:
public GetFilesInFolder(string folderPath)
{
return this.Directory.GetFiles(folderPath)
}
Run Code Online (Sandbox Code Playgroud)
但是由于System.IO类是静态类,因此不会出现这种情况.据我所知,他们既不能以这种方式实例化,也不能用于嘲笑的目的.
创建一个包含简单重定向到System.IO的函数的类.创建另一个伪造/模拟System.IO的类.让这两个类都实现一个通用接口.然后你不必担心System.IO充满静态的事实.
| 归档时间: |
|
| 查看次数: |
227 次 |
| 最近记录: |