TDD和报告的最佳实践

Question

我想更加熟悉测试驱动的方法。我的一个缺点是我的代码的主要部分是生成报告的上下文（PDF文档，图表图像）。总是有一个复杂的设计人员参与其中，并且不存在正确性的简单测试。没有机会测试片段！

你知道这种情况下的TDD实践吗？

Answer 1

您可以使用验收测试驱动开发来替换单元测试，并具有用作参考的已知数据的验证报告。

然而，这种测试并没有像单元测试那样给出细粒度的诊断，他们通常只提供PASS/FAIL结果，并且如果报告经常变化，则需要重新生成和重新验证以及。

Answer 2

您可以尝试为报告数据源使用Web服务并测试该服务，但是您不会为渲染进行单元测试。这与测试视图时的问题完全相同。当然，你可以使用像Selenium这样的网络测试框架，但是你可能不会实践真正的TDD。代码完成后，您将创建测试。

总之，使用常识。尝试测试报告的呈现可能没有意义。您可以手动测试案例，测试人员必须手动完成这些测试案例，或者亲自检查报告。

你可能也想看看“How Much Unit Test Coverage Do You Need? - The Testivus Answer”

Answer 3

我问自己，在这些情况下的问题是“我怎么知道我这样做是正确”？

我在自己的职业生涯中写了很多代码，几乎所有代码都没有在第一次运行。几乎每次我回过头来改变代码以进行重构，功能改变，性能或错误修复时，我都会再次破坏它。 TDD保护我免于自我（谢天谢地！）。

在生成的代码的情况下，我不觉得有必要测试代码。也就是说，我相信代码生成器。但是，我确实想要将我的输入测试到代码生成器。具体怎么做取决于具体情况，但一般的做法是问自己，我可能会犯错，然后找出如何确认我是否正确。

也许我写了一个自动化测试。也许我会手动检查某些东西，但这非常危险。也许别的东西。这取决于实际情况。

Answer 4

某些应用程序或框架只是继承了单元测试不友好的状态，实际上并没有太多可以做的事情。我倾向于完全避免这样的框架，但如果绝对不得不处理这些问题，将所有逻辑抽取到可测试的库中会很有帮助，而只在框架中留下声明性代码。

Answer 5

为了把一个稍微不同的自旋马克塞曼和Jay Bazuzi答案：

你的问题是报告前端产生的输出，你不能轻易的“验证”部分检查数据格式的试验。

来处理这类问题的方法是：

1. 有一些非常高层次的集成测试表面上确认您的后端代码挂钩正确到您的前端代码。我通常称这些测试为“烟雾测试”，如“如果我打开电源并且它抽烟，这很糟糕”。

2. 查找测试后端报告代码的其他方法。既可以测试中间输出数据结构，也可以实现更易于测试的备用输出前端，HTML，纯文本等等。

这与测试网络应用程序的常见问题类似：无法自动测试“网页看起来不错”。但是，测试页面数据中的词语和数字是否正确（使用机械化和页面刮除器等程序化浏览器）并且如果页面严重依赖时有几个表面功能测试（使用Selenium或Windmill）就足够了在Javascript上。

Answer 6

考虑从PDF中提取文本并检查它。但是，这不会给你格式。如果图表在pdf中，某些pdf抽取程序可以抽出图像。

Answer 7

面对这种情况，我尝试了两种方法。

1. The Golden Master approach。生成报告一次，自己检查一下，然后将其保存为“黄金大师”。编写一个自动化测试，将其输出与黄金大师进行比较，并在两者不同时失败。

2. 自动完成数据的测试，但手动检查格式。我自动检查生成报告数据的模块，但为了检查报告格式，我生成了具有硬编码值的报告并手动检查报告。

我强烈建议您不生成完整的报告只是为了检查报表上的数据的正确性。当你想检查报告（而不是数据），然后生成报告;当你想检查数据（而不是格式）时，只能生成数据。