我有一个方法ExportXMLFiles(string path)
来导出某个路径上的xml文件,其中包含一些元素,如FirstName,LastName,MajorSubject。这些值将从数据库中挑选出来。
现在我需要为它编写一个单元测试方法,除了简单和直接的测试之外我还没有进行过多次单元测试。我的困惑是,我是否需要连接到数据库并创建XML文件,还是需要在创建XML文件时传递硬编码值,以便我可以验证XML中创建的值?
还有其他办法吗?
答案 0 :(得分:2)
您绝对不希望在单元测试中使用实际的数据库。它增加了您不希望在单元测试中处理的一个复杂程度。它还使您的单元测试不太可靠和慢。看看是否可以将数据库功能分解为可以使用模拟框架实例化的接口。尝试查看moq之类的内容,或者如果还不够,请查看Microsoft的moles。
编辑 - 另一篇文章提到,如果功能是写入磁盘,那么单元测试应验证文件是否已写入磁盘。使用Moles,您可以模拟文件系统并测试文件系统调用并模拟写入失败或您需要的任何其他情况,这将比实际物理写入磁盘提供更多的灵活性和速度。像磁盘写入失败这样的东西在没有像鼹鼠这样的东西的情况下进行测试会很痛苦。
答案 1 :(得分:0)
单元测试的范围应该很小,并且与依赖关系隔离,例如数据库和文件系统。因此,您要做的是查看模拟数据库访问以及将什么写入文件,以便您可以运行测试而无需数据库中的特定值。单元测试应该快速运行,具有可重复的结果(即运行两次,获得相同的答案),与其他测试隔离并且能够以任何顺序运行。
单元测试正在查看一项功能,而不是依赖于其他任何行为。
因此,请考虑使用依赖注入等模式,以便提供(即注入)数据库和文件系统依赖性。查看一个模拟框架(如NMock)或编写自己的轻量级虚假对象,这些对象实现与依赖项相同的接口,然后您可以将它们传递到正在测试的函数中。
答案 2 :(得分:0)
这种方法有什么责任? 它是以特定路径以xml文件的形式转储给定数据吗?如果是,那么您必须检查文件是否实际创建。
这不是单元测试,而是集成测试(因为这是应用程序和文件系统之间边界的类)。您应该通过接口/角色抽象出输入数据源(DB)。你也可以创建一个CreateXmlFile(内容)的角色,但我认为这太过分了。
// setup mock data source to supply canned data
// call myObject.ExportToXml(mockDataSource, tempPath)
// verify files are created in tempPath
最后,这个类需要实现一个Role(DataExporter),以便使用DataExporter的测试很快/不必处理文件系统(或XML)。