我应该如何对返回XML的“存储库”进行单元测试？

Question

对于一个项目，我有一系列伪存储库，它们通过调用一些返回XML的存储过程来创建XML（它们不是真正的存储库，而是填充相同的角色，因此我已经使用了这个术语）。出于我的项目的目的，我还有“Mappers”（同样它们不是 true mappers ...），它们将XML作为输入并使用Linq将原始XML转换为DTO。

由于我有映射器，在我看来，“存储库”不应该测试返回的值（因为这是映射器的工作;存储库只关心它返回一些XML，无论是否XML数据是正确的）。但是，这会导致测试确实只是确保“存储库”的返回值不为空。

基本上每个存储库都实现一个接口，该接口具有一个名为GetXml的方法，该方法返回一个XML文档。实际的实现执行数据库调用，但是对于测试，我有一个非常基本的模拟类，它只返回一个空白的XML文档。最后，我需要使用模拟的一些硬编码值来构建一个实际的XML文件，但是“存储库测试基本上是一行”是“没问题”：Assert.IsNotNull(repository.GetXml(), "Xml response was null");

这是甚至应该测试的东西，还是有更好的方法来测试它而不需要踩踏映射器的脚趾？我想从设计的角度来看，我可以完全删除映射器，只需让存储库自己进行映射（或使映射器在存储库内部）。我没有做TDD，因为我实际上已经编写了代码，但我想创建测试，因此它更容易测试，因此我可以向我的同事展示测试的好处（我们目前不使用任何类型的自动化测试。）

我想我真正问过这个问题：是否可以编写一个仅表达设计意图的测试给可能使用该代码的人，而不是真正关心返回的值？现在这就是这些测试的作用：他们说，在代码中，“我应该能够创建一个XmlXXXRepository类来实现一个名为IXmlRepository的接口，在构造时需要一个长的quoteID ，并有一个名为GetXml()的方法，它返回一个XmlDocument对象“就是这样。

Answer 1

我通常会为XML方法编写两种类型的测试。首先，我为创建XML结果所涉及的逻辑编写单元测试。这通常会强制您将逻辑​​提取到另一个类中，以便逻辑和XML创建分离。这通常意味着逻辑最终会填充DTO，而XML是使用某种构建器类或简单的XML序列化器从生成的DTO创建的。

一旦单元测试了所有工作，我就开始使用一组已知的输入和已知的XML输出创建集成测试。根据XML结果，这可以是非常简单的文本比较，也可以是一系列XPath查询，以验证XML中的结构和值。

哦，MBUnit中的XML assertions非常适合这种测试。