我应该如何对“存储库”进行单元测试？返回 XML？
对于一个项目，我有一系列伪存储库，它们通过调用一些返回 XML 的存储过程来创建 XML（它们不是真正的存储库，但具有相同的角色，因此我采用了该命名法）。出于我的项目的目的，我还有“映射器”（同样，它们不是真正的映射器...），它们将 XML 作为输入并使用 Linq 将原始 XML 转换为 DTO。
因为我有映射器，所以在我看来，“存储库”不应该测试返回的值（因为这是映射器的工作；存储库只关心它是否返回了一些 XML，无论 XML 数据是否是正确的）。然而，这导致测试实际上只是确保“存储库”的返回值不为空。
基本上，每个存储库都实现一个接口，该接口具有一个名为 GetXml 的方法，该方法返回 XML 文档。实际的实现是进行数据库调用，但为了测试，我有一个非常基本的模拟类，它只返回一个空白的 XML 文档。最终，我需要使用一些硬编码值来构建一个实际的 XML 文件，但是存储库测试本质上是一行，这是否“可以”：Assert.IsNotNull(repository.GetXml(), “Xml 响应为空”);
这是应该测试的东西，还是有更好的方法来测试它，而不需要踩到映射器的脚趾？我想从设计的角度来看，我可以完全删除映射器，然后让存储库本身进行映射（或者使映射器位于存储库内部）。我没有进行 TDD，因为我实际上已经编写了代码，但我想创建测试，以便更容易测试，这样我就可以向我的同事展示测试的好处（我们目前不使用 任何类型的自动化测试）。
我想我真正想问的是：是否可以编写一个仅向可能使用代码的人表达设计意图的测试，而不真正关心返回的值？现在，这就是这些测试所做的：他们在代码中说，“我应该能够创建一个 XmlXXXRepository 类，该类实现一个名为 IXmlRepository 的接口，需要很长时间调用< code>quoteID 在构造时，并且有一个名为 GetXml() 的方法，该方法返回一个 XmlDocument 对象”，仅此而已。
For a project I have a series of pseudo-repositories that create XML (they aren't true repositories but fill the same role so I've gone with that nomenclature) by calling some XML-returning stored procs. For purposes of my project I also have "Mappers" (again they aren't true mappers...) that take the XML as input and uses Linq to translate the raw XML to DTOs.
Since I have the mapper, it seems to me that the "repository" shouldn't be testing the value returned (since that's the job of the mapper; the repository only cares that it got some XML back, whether or not the XML data is correct). However, this results in tests that are literally just making sure that the return value from the "repository" isn't null.
Basically each repository implements an interface that has a single method called GetXml that returns an XML document. The actual implementation does the database call, but for the test I have a very basic mock class that just returns a blank XML document. Eventually I will need to build up an actual XML file using some hard-coded values for the mock, but is it "okay" that the repository tests are essentially a single line: Assert.IsNotNull(repository.GetXml(), "Xml response was null");
Is this something that should even be tested, or is there a better way to test this without treading on the toes of the mapper? I suppose from a design standpoint I could remove the mappers completely and just have the repository do the mapping itself (or make the mapper internal to the repository). I'm not doing TDD, as I actually have the code written but I'm wanting to create tests so it's easier to test, and so I can show my co-workers the benefits of tests (we don't currently use any type of automated testing).
I guess what I'm really asking it this: Is it okay to write a test that only expresses a design intention to someone who may use the code, without actually caring about the value returned? Right now that's what these tests do: They say, in code, "I should be able to create an XmlXXXRepository class that implements an interface called IXmlRepository, takes a long called quoteID upon construction, and has a method called GetXml() that returns an XmlDocument object" and that's it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常为 XML 方法编写两种类型的测试。首先，我为创建 XML 结果所涉及的逻辑编写单元测试。这通常会迫使您将逻辑提取到另一个类中，以便将逻辑和 XML 创建分开。这通常意味着逻辑最终会填充 DTO，并且使用某种构建器类或简单的 XML 序列化程序根据生成的 DTO 创建 XML。
一旦单元测试全部工作，我就开始使用一组已知的输入和已知的 XML 输出创建集成测试。根据 XML 结果，这可以是非常简单的文本比较，也可以是一系列 XPath 查询来验证 XML 中的结构和值。
哦，MBUnit 中的 XML 断言 对于这种类型来说非常棒测试。
I usually write two types of tests for my XML methods. First I write unit tests for the logic involved with creating the XML result. This usually forces you to extract your logic into another class so that the logic and the XML creation are separated. Which usually means the logic ends up filling in a DTO and the XML is created off of the resulting DTO using some sort of builder class or simple XML serializer.
Once the unit tests all work, I start creating integration tests with a known set of inputs and known XML outputs. Depending on the XML result, this can be either very simple text comparison or a series of XPath queries to validate the structure and the values in the XML.
Oh and the XML assertions in MBUnit are terrific for this kind of testing.