我知道强烈建议您与文件系统分开运行单元测试,因为如果您在测试过程中触摸文件系统,那么您还可以测试文件系统本身.好的,这是合理的.
我的问题是,如果我要测试文件保存到磁盘,我该怎么办？与数据库一样,我分开一个负责数据库访问的接口,然后为我的测试创建另一个实现？还是还有其他一些方法？
我的问题是,如果我要测试文件保存到磁盘,我该怎么办？与数据库一样,我分开一个负责数据库访问的接口,然后为我的测试创建另一个实现？还是还有其他一些方法？
我对此的态度对我刚才读到的
Growing Object-Oriented Software Guided by Tests(GOOS)书有很大的偏见,但这是我今天所了解的最好的.特别：
原文链接：https://www.f2er.com/javaschema/281885.html>创建一个接口,从代码中抽出文件系统.将这个类作为协作者/依赖关系来模拟它.这样可以快速地进行单元测试和反馈.
>创建测试接口实际实现的集成测试.即验证调用Save()实际上将文件保留到磁盘并具有写入内容(使用引用文件或解析它应包含的几项内容)
>创建验收测试,测试整个系统 – 端到端.在这里,您可以验证是否创建了一个文件 – 此测试的目的是确认实际的实现是否正确连接/插入.
评论者更新：
如果您正在读取结构化数据(例如Book对象)(如果不为IEnumerable替换字符串)
interface BookRepository
{
IEnumerable<Books> LoadFrom(string filePath);
void SaveTo(string filePath,IEnumerable<Books> books);
}
现在,您可以使用构造函数注入将模拟注入到客户端类中.客户类单元测试很快;不要命中文件系统.他们只是验证是否对依赖项调用了正确的方法(例如加载/保存)
var testSubject = new Client(new Mock<BookRepository>.Object);
接下来,您需要创建一个BookRepository的真正实现,它可以在文件(或者如果你想要的时候使用sql DB).没有人必须知道.
为FileBasedBookRepository(实现上述Role)编写集成测试,并测试使用引用文件调用Load给出正确的对象,并使用已知列表调用Save,将其持续到磁盘.即使用真实的文件这些测试会很慢,所以用标签标记或将其移动到单独的套件.
[TestFixture]
[Category("Integration - Slow")]
public class FileBasedBookRepository
{
[Test]
public void CanLoadBooksFromFileOnDisk() {...}
[Test]
public void CanWriteBooksToFileOnDisk() {...}
}
最后应该有一个/多个验证测试,用于执行加载和保存.
