HUnit/QuickCheck 与持续集成
HUnit 或 QuickCheck 是否有允许持续集成系统的扩展，例如 Bamboo< /a> 做详细的测试结果报告？
到目前为止，我最好的想法是简单地触发测试作为构建脚本的一部分，并依赖测试以非零退出代码失败。这对于在测试失败时引起注意非常有效，但会将构建失败与测试失败混淆，并且需要费力地查看控制台输出来确定问题的根源。
如果这是当前工具的最佳选择，我的想法是为 HUnit 编写一个报告模块，它将在 JUnit XML 格式，然后将 CI 工具指向它，就好像它正在报告 Java 项目一样。不过，这似乎有点老套，所以我很感激您对现有选项和新开发方向的想法。
Are there any extensions to HUnit or QuickCheck that allow a continuous integration system like Bamboo to do detailed reporting of test results?
So far, my best idea is to simply trigger the tests as part of a build script, and rely on the tests to fail with a non-zero exit code. This is effective for getting attention when a test fails, but confuses build failures with test failures and requires wading through console output to determine the problem's source.
If this is the best option with current tools, my thought is to write a reporting module for HUnit that would produce output in the JUnit XML format, then point the CI tool at it as though it were reporting on a Java project. This seems somewhat hackish, though, so I'd appreciate your thoughts both on existing options and directions for new development.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
test-framework包提供了使用不同测试范例集成测试的工具，包括HUnit和QuickCheck，可以向其控制台测试运行程序传递一个标志，使其生成与 JUnit 兼容的 XML。我们将它与 Jenkins 一起使用以进行持续集成。
调用示例：
The test-framework package provides tools for integrating tests using different testing paradigms, including HUnit and QuickCheck, and its console test runner can be passed a flag that makes it produce JUnit-compatible XML. We use it with Jenkins for continuous integration.
Invocation example:
我刚刚发布了一个包，它根据包含 QuickCheck 属性的模块生成测试套件： http:// hackage.haskell.org/package/tasty-integrate
目前，这比 test-framework/tasty 高出一步，因为它强制将它们从文件系统中拉出/聚合，而不是依赖于每个文件的记录保留。我希望这对您的 CI 流程有所帮助。
I've just released a package which generates test-suites based off modules containing quickCheck properties: http://hackage.haskell.org/package/tasty-integrate
This is one step above test-framework/tasty at the moment, as it forcefully pulls/aggregates them off the filesystem, instead of relying upon per-file record keeping. I hope this helps your CI process.