规范的XML测试

我最近为客户做了几天的TDD培训。 他们要求我帮助他们测试和重构从内部域模型创建XML的类。 这使我有机会研究更大的模式。

我想知道域模型从何而来。 查看代码库，我发现许多地方处理了相同或相似的数据结构。 通常，我还发现了一些代码，可以解析 XML结构并输出域模型。 这样就可以使用我最喜欢的测试映射代码的方式：往返。

通用模式：要测试翻译代码，可以将编码和解码作为一个测试。 这些测试在可读性和错误检测率方面通常会给您带来很多实惠。 它们的主要局限性在于它们可能无法很好地利用代码的所有路径。 如果这是一个问题，则应使用更细粒度的测试来补充它们。

之前我已经处理过几次此类问题，所以我决定创建自己的XML库Eaxy （与您一样）。 我在测试中介绍了该库，但是生产代码仍然使用DOM和JAXB的组合。 这是测试的合理复制：

@Test
public void shouldReadHtml() {
    Element input =
    	el("people",
            el("person",
            		el("name",
            			el("firstName", "Johannes"),
            			el("lastName", "Brodwall")),
                    el("contact info",
                    	el("address", "Test Street 42"),
                    	el("postalCode", "4242"),
                    	el("phoneNumber", "5552224444"));
 
    File testFile = createTmpFile();
    input.writeTo(testFile);
    // The names of domain objects are on purpose poor, to reflect
    //  that this is often useful with legacy code
    PersonListExchanger exchange = new XmlToPersonService().read(testFile);
 
    Element output = new PersonXmlDataCreator().createXml(exchange);
 
    assertThat(input.toIndentedXml())
    	.isEqualTo(output.toIndentedXml());
}

当我将此测试引入现有代码库时，我们发现了一些有趣的东西：

1. XML文件中存在内部依赖关系，开发人员没有意识到，因为所有固定的测试数据都由巨大的文件组成，没有人会读取。
2. 字段是从base64解码的，但在内部将其视为仍进行了编码，从而在输出中对其进行了双重编码。
3. 输出结构与输入结构略有不同。

该测试与覆盖率测量相结合，使我们有足够的信心来重构团队将来依赖的一些相当复杂的代码。 往返测试可以为您带来很多收益。

翻译自: https://www.javacodegeeks.com/2018/06/canonical-xml-test.html