TDD 和报告的最佳实践
我正在尝试更加熟悉测试驱动方法。对我来说，一个缺点是我的代码的主要部分是生成报告上下文（PDF 文档、图表图像）。总是有一个复杂的设计者参与其中，并且没有简单的正确性测试。没有机会只测试片段！
您知道针对这种情况的 TDD 实践吗？
I am trying to become more familiar with test driven approaches. One drawback for me is that a major part of my code is generated context for reporting (PDF documents, chart images). There is always a complex designer involved and there is no easy test of correctness. No chance to test just fragments!
Do you know TDD practices for this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
某些应用程序或框架本质上对单元测试不友好，对此您无能为力。
我更喜欢完全避免使用此类框架，但如果绝对被迫处理此类问题，将所有逻辑提取到可测试的库中，只在框架中留下声明性代码会很有帮助。
Some applications or frameworks are just inheritently unit test-unfriendly, and there's really not a lot you can do about it.
I prefer to avoid such frameworks altogether, but if absolutely forced to deal with such issues, it can be helpful to extract all logic into a testable library, leaving only declarative code behind in the framework.
在这些情况下我问自己的问题是“我怎么知道我做对了”？
在我的职业生涯中，我写过很多代码，几乎所有代码第一次都不起作用。几乎每次我回去更改代码以进行重构、功能更改、性能或错误修复时，我都会再次破坏它。 TDD 保护我免受我自己的伤害（谢天谢地！）。
对于生成的代码，我不觉得有必要测试代码。也就是说，我信任代码生成器。但是，我确实想测试我对代码生成器的输入。具体如何做到这一点取决于具体情况，但一般的方法是问自己为什么我可能会出错，然后找出如何验证我是否做对了。
也许我写一个自动化测试。也许我会手动检查一些东西，但这非常危险。也许还有别的东西。这取决于具体情况。
The question I ask myself in these situations is "how do I know I got it right"?
I've written a lot of code in my career, and almost all of it didn't work the first time. Almost every time I've gone back and changed code for a refactoring, feature change, performance, or bug fix, I've broken it again. TDD protects me from myself (thank goodness!).
In the case of generated code, I don't feel compelled to test the code. That is, I trust the code generator. However, I do want to test my inputs to the code generators. Exactly how to do that depends on the situation, but the general approach is to ask myself how I might be getting it wrong, and then to figure out how to verify that I got it right.
Maybe I write an automated test. Maybe I inspect something manually, but that's pretty risky. Maybe something else. It depends on the situation.
对 Mark Seemann 和 Jay Bazuzi 的答案稍有不同：
您的问题是报告前端生成一种数据格式，您无法在测试的“验证”部分轻松检查其输出。
处理此类问题的方法是：
进行一些非常高级的集成测试，从表面上验证您的后端代码是否正确挂钩到前端代码中。我通常将这些测试称为“冒烟测试”，例如“如果我打开电源并且冒烟，那就很糟糕”。
寻找不同的方法来测试您的后端报告代码。要么测试中间输出数据结构，要么实现一个更易于测试的替代输出前端，HTML、纯文本等。
这类似于测试 Web 应用程序的常见问题：无法自动测试“页面看起来正确”。但测试页面数据中的文字和数字是否正确（使用机械化和页面抓取等编程浏览器）就足够了，如果页面严重依赖，则进行一些表面功能测试（使用 Selenium 或 Windmill）关于 JavaScript。
To put a slightly different spin on answers from Mark Seemann and Jay Bazuzi:
Your problem is that the reporting front-end produces a data format whose output you cannot easily inspect in the "verify" part of your tests.
The way to deal with this kind of problem is to:
Have some very high-level integration tests that superficially verify that your back-end code hooks correctly into your front-end code. I usually call those tests "smoke tests", as in "if I turn on the power and it smokes, it's bad".
Find a different way to test your back-end reporting code. Either test an intermediate output data structure, or implement an alternate output front-end that is more test-friendly, HTML, plaintext, whatever.
This similar to the common problem of testing web apps: it is not possible to automatically test that "the page looks right". But it is sufficient to test that the words and numbers in the page data are correct (using a programmatic browser surch as mechanize and a page scraper), and have a few superficial functional tests (with Selenium or Windmill) if the page is critically dependent on Javascript.
您可以尝试使用 Web 服务作为报告数据源并对其进行测试，但您不会对渲染进行单元测试。这与测试视图时遇到的问题完全相同。当然，您可以使用像 Selenium 这样的 Web 测试框架，但您可能不会练习真正的 TDD。代码完成后，您将创建测试。
简而言之，运用常识。尝试测试报告的呈现可能没有意义。您可以拥有测试人员必须手动完成的手动测试用例，或者只是自己检查报告。
您可能还想查看“单元测试覆盖率是多少您需要吗？ - Testivus 答案”
You could try using a web service for your reporting data source and test that, but you are not going to have unit tests for the rendering. This is the exact same problem you have when testing views. Sure, you can use a web testing framework like Selenium, but you probably won't be practicing true TDD. You'll be creating tests after your code is done.
In short, use common sense. It probably does not make sense to attempt to test the rendering of a report. You can have manual test cases that a tester will have to go through by hand or simply check the reports yourself.
You might also want to check out "How Much Unit Test Coverage Do You Need? - The Testivus Answer"
您可以使用验收测试驱动的开发来替换单元测试，并为用作参考的众所周知的数据提供经过验证的报告。
然而，这种测试不能像单元测试那样提供细粒度的诊断，它们通常只提供通过/失败结果，并且如果报告经常更改，则还需要重新生成和重新验证参考。
You could use Acceptance Test driven Development to replace the unit-tests and have validated reports for well known data used as references.
However this kind of test does not give a fine grained diagnostic as unit-tests do, they usually only provide a PASS/FAIL result, and, should the reports change often, the references need to be regenerated and re-validated as well.
考虑从 PDF 中提取文本并进行检查。然而，这不会给你格式化。如果 pdf 中有图表，一些 pdf 提取程序可以提取图像。
Consider extracting the text from the PDF and checking it. This won't give you formatting, however. Some pdf extraction programs can pull out the images if the charts are in the pdf.
面对这种情况，我尝试了两种方法。
黄金大师的方法。生成一次报告，自己检查一下，然后保存为“金主”。编写一个自动化测试来将其输出与黄金大师进行比较，并在它们不同时失败。
自动测试数据，但手动检查格式。我自动检查生成报告数据的模块，但为了检查报告格式，我生成带有硬编码值的报告并手动检查报告。
我强烈建议您不要仅仅为了检查报告中数据的正确性而生成完整的报告。当你想检查报告（不是数据）时，那就生成报告；当您想检查数据（而不是格式）时，只需生成数据即可。
Faced with this situation, I try two approaches.
The Golden Master approach. Generate the report once, check it yourself, then save it as the "golden master". Write an automated test to compare its output with the golden master, and fail when they differ.
Automate the tests for the data, but check the format manually. I automate checks for the module that generates the report data, but to check the report format, I generate a report with hardcoded values and check the report by hand.
I strongly encourage you not to generate the full report just to check the correctness of the data on the report. When you want to check the report (not the data), then generate the report; when you want to check the data (not the format), then only generate the data.