使突变测试的单元测试快速失败

发布于 2024-07-16 21:25:14 字数 477 浏览 3 评论 0原文

突变测试遇到的一个问题是它很慢,因为默认情况下你会进行完整的测试运行(生成的每个突变的测试文件或一组测试文件)。

加快突变测试速度的一种方法是,一旦遇到单个故障(但仅在突变测试期间),就停止给定突变体的测试运行。 更好的是突变测试者记住杀死最后一个突变体的第一个测试是什么,并将其首先给予下一个突变体。 ruby 中是否有任何东西可以执行这些操作,或者是我开始猴子修补的最佳选择?

(是的,我知道单元测试应该很快。并且显示所有失败的测试在突变测试之外很有用,因为它不仅可以帮助您识别出问题,还可以查明哪里出了问题)

编辑:我目前正在使用 heckle 和 test/unit。 如果测试/单元不可能记住运行之间哪些测试失败,也许 heckle 或正在运行的 heckle 可以记住它。

One problem encountered with mutation testing is that it's slow, because by default you do a full test run (either a test file, or a suite of test files) for each mutation generated.

One way to make mutation testing faster would be to stop the test run for a given mutant once a single failure has been encountered (but only during mutation testing). Even better would be for the mutation tester to remember what was the first test to kill the last mutant, and give that first to the next mutant. Is there anything in ruby that does either of these things, or is my best bet to start monkey patching?

(Yes, I know unit tests ought to be fast. And showing all of the failed tests is useful outside of mutation testing, as it helps you not merely identify that something's wrong, but pinpoint where it's going wrong)

Edit: I'm currently using heckle with test/unit. If it's not possible for test/unit to remember which tests fail between runnings, maybe heckle or something running heckle could remember it.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

烦人精 2024-07-23 21:25:14

最好的方法是从 github 查看 heckle 源代码,修补它,然后提交该补丁给开发人员。 您应该能够编写一个自定义测试运行程序来进行质询。

猴子修补永远不是此类问题的答案。 事实上,猴子补丁几乎从来都不是解决问题的办法。

Your best best is to check out the heckle source from github, patch it, and submit that patch to the developers. You ought to be able to write a custom test runner for heckle.

Monkey patching is never the answer for something like this. In fact, monkey patching is almost never the answer for anything.

悟红尘 2024-07-23 21:25:14

我的 mutant 工具使用 rspec2 --fail-fast 选项立即停止一次遇到了一个失败的例子。 与仅执行受影响的单元测试的 --rspec-dm2 策略一起,我们可以获得非常快速的突变覆盖测试。 请参阅此 asciicast 进行(速度)演示。

My mutant tool uses the rspec2 --fail-fast option to stop immediately once a failing example was encountered. Together with the --rspec-dm2 strategy that only executes affected unit tests we get very fast mutation coverage testing. See this asciicast for a (speed) demonstration.

淡笑忘祈一世凡恋 2024-07-23 21:25:14

我开始使用的一种方法是为每种方法编写单元测试,并将它们放在单独的文件中,像 ruby​​specs 一样组织。 我单独运行每个规范,指定我想要询问的确切方法。 我有一个 rake 任务来管理所有这些,并在最后打印一份报告,其中包含失败的突变(如果有)。

最后,我对每种方法都进行了全面的讨论,而无需永远等待结果。 另外,它甚至比每个人使用的正常方法更好,因为我没有得到任何偶然的覆盖——每种方法的规范必须涵盖该方法的所有突变。

One approach I've started using was writing unit tests for each method, and putting them in separate files, organized like rubyspecs. I run each spec in isolation, specifying the exact method I want to heckle. I have a rake task that manages all this and prints a report at the end with failing mutations, if any.

In the end I get full heckle coverage of each method, without waiting forever for the results. Plus it's even better than the normal approach everyone uses, because I don't get any incidental coverage -- each methods's specs must cover all mutations of that method.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文