我对这种做法的态度在(GOOS)》书指导着面向目标的软件的发展,但这符合我今天所知的最佳情况。 具体地说:
- Create an interface to abstract away the file system from your code. Mock it where this class is needed as a collaborator/dependency. This keeps your unit-tests quick and feedback fast.
- Create integration tests that test the actual implementation of the interface. i.e. verify that calling Save() actually persists a file to disk and has the write contents (use a reference file or parse it for a few things that it should contain)
- Create an acceptance test that tests the whole system - end to end. Here you may just verify that a file is created - the intent of this test is to confirm if the real implementation is wired / plugged in correctly.
评论员最新情况:
如果您重读结构化的数据(如书目) (如果不能用数字表示)
interface BookRepository
{
IEnumerable<Books> LoadFrom(string filePath);
void SaveTo(string filePath, IEnumerable<Books> books);
}
现在,你可以使用建筑注射器向客户阶层注入一ck。 客户类别unit检测 因此,没有击中文档系统。 他们只是核实,正确的方法取决于受扶养人(如Load/Save)。
var testSubject = new Client(new Mock<BookRepository>.Object);
Next you need to create the real implementation of BookRepository that works off a File (or a Sql DB tommorrow if you want it). No one else has to know.
Write integration tests for FileBasedBookRepository (that implements the above Role) and test that calling Load with a reference file gives the right objects and calling Save with a known list, persists them to the disk. i.e. uses real files These tests would be slow so mark them up with a tag or move it to a separate suite.
[TestFixture]
[Category("Integration - Slow")]
public class FileBasedBookRepository
{
[Test]
public void CanLoadBooksFromFileOnDisk() {...}
[Test]
public void CanWriteBooksToFileOnDisk() {...}
}
最后,应当有一个/更多的<>接受测试,该试验可操作Load和 Save。
