我应该单元测试XML模式吗？

Question

我正处于为我的工作企业应用程序编写XML模式的最初阶段。要验证的XML表示一个应用程序 - 类似于Winforms - 表单，网格，菜单等，但没有布局。

XSD的主要目的不在于验证XML，而在于为XML文件添加设计时可发现性，以便获得可用元素和属性的IntelliSense。

当我编写模式时，我发现自己正在执行TDD的元素并根据模式验证文档，更改文档或模式中的元素/属性以使验证无法确保我正在编写模式正确。

这给我带来了一个问题：我是否应该对模式进行单元测试，只是在它上面抛出一些XML的排列，并确保它的行为应该如何。

这对我来说肯定是有意义的，因为我的XSD-fu很糟糕，而且我想更确定XSD本身就是一个规范，这是正确的。

Answer 1

一般来说，我觉得很难测试XSD模式：

• 对于XSD往往域的造型是关键，往往我没有与XSD问题构建本身，而是我分析了域错误。
• 生成的模型不是基于XSD本身，而是基于绑定配置（例如JAXB for Java）。所以最后你的测试太多了。
• 这样的测试取决于很多事情往往会经常中断，特别是当您重构XSD时。

到底要提高质量XSD我喜欢：

• 拥有XSD文件的早期的评论（由同事或QA）。让实际人员看着他们（包括XSD和XML实例）发现了自动化测试永远不会发现的缺陷。
• 对生成的XML实例执行集成测试。这些集成测试可以自动进行。

Answer 2

如果您对XSD不太好，那么我建议您使用TDD构建XSD。也就是说，创建一个失败的单元测试，涉及验证一些你想要工作的XML，以及一个不允许它验证的XSD。然后，更新XSD以允许该XML验证。然后，重构测试和XSD，重复测试。

Answer 3

我想没有理由不单元测试XML模式。 如果它是代码（它是），那么TDD将倾向于测试它。

另一个问题将是如何去做呢？ 一个简单的方法是创建两组示例xml文件，一个包含根据您的设计无效的所有文件，另一个包含有效的文件。然后简单地用你的xml解析器解析每个组并声明结果。

但实际的挑战在于创建示例xml文件。特别是如果你也在同时发展你的设计。