“单元测试”报告

Question

您如何“单元测试”某些报表引擎（如Crystal Reports或SQL Server Reporting Services）创建的报表？

Answer 1

为了测试我们自己的基于Java的报告产品i-net Clear Reports，我们运行一系列测试报告，将它们导出为各种导出格式，确保输出符合要求，然后继续使用它们报告每天运行，将结果与原始数据进行比较。然后，任何差异都会显示为测试失败。

它对我们来说效果很好。这样做的缺点是，在重置测试数据之前，任何可能没有任何差异的细微差别都会显示为测试失败。

旁注：这不是单元测试，而是验收测试。但我不明白你怎么能真正“整体测试”整个报告。

Answer 2

报告的问题类似于GUI的问题。 如果报告/ GUI有很多（错位的）情报，那将使测试变得困难。 然后解决方案是

• Separated Presentation：将内容与内容分开（数据访问/域/业务规则）。在当前上下文中，您将创建某种反映最终报表内容的ViewModel类（例如，如果您的报表中包含订单详细信息和订单项，则此类应具有详细信息的属性和行列表项目对象）。 ViewModel可以无限简单地进行测试。应用内容的最后一英里应该是相对简单的（瘦UI） e.g。如果使用xslt呈现报表，则可以使用XmlUnit或字符串比较等工具测试数据xml。对于最终报告，您可以对数据xml上的xsl转换有合理的信心......此处的任何错误都很容易解决。
• 但是，如果您使用Crystal Reports等第三方供应商，则无法控制/访问报告生成。在这种情况下，您可以做的最好的事情是生成名为Golden Files的代表性/预期输出文件（例如pdfs）。在测试中将此作为只读资源用于比较实际输出。然而，这种方法非常脆弱......因为对报告生成代码的任何实质性更改都可能导致所有以前的Golden文件不正确。所以他们必须重新生成。如果自动化的成本效益比太高，我会说Go手册与老式的单词doc测试计划。

Answer 3

我能想到的最好的方法是将结果与预期的输出进行比较。

也许可以添加一些智能，但测试这些大块并不容易。

Answer 4

我同意Gamecat。

从固定（常量）数据生成报告，并将其与该数据的预期输出进行比较。

之后，您可以使用简单的测试，例如diff（检查文件是否相同）

Answer 5

我目前的想法是在两个级别创建测试：

• 单元测试：构建报告以使用一些想法来测试UI，例如Humble View。报告本身将尽可能愚蠢。它应该主要包括简单的字段绑定。然后，可以对作为这些绑定源的数据项/对象进行单元测试。

• 接受测试：生成一些示例报告。先用手验证。然后设置一个自动测试，使用diff进行比较。