我正在尝试运行WordPress自动测试，如中所述this article. 不出所料，我已经得到了很多跳过的测试标记S, 因为，根据这篇文章，“这通常意味着测试链接到bug报告，而bug报告仍然没有修复。”我也想将测试与bug报告联系起来，但我很难找到有关如何做到这一点的信息。如何将测试链接到bug报告？我可以在GitHub问题上也这样做吗？
编辑：好的，我在同一篇文章中发现了这一点：“许多测试都用@ticket注释标记，这表明它们是WordPress Trac ticket的结果。如果ticket仍然打开，则跳过测试–在这种情况下，我们将测试视为可能失败的“已知错误”
我发现tests/phpunit/includes/testcase.php -> knownWPBug( $ticket_id ), 但我很想知道是否有像这样的GitHub门票库TracTickets 这样我就可以轮询我的GitHub repo，查看问题是否存在。
我不知道有什么图书馆，但你可以用TracTickets 作为指南并使用GitHub的API。
我实际上是想说don\'t do this. WordPress实际上不再使用这种跳过测试的方法。看见ticket #30284. 我在这里引用：
我们以前的约定是编写单元测试来演示bug，用@ticket 标记，并将其提交给回购。然后，在运行套件时，WP_UnitTestCase::knownWPBug() 将从Trac获得一个开放票证列表，并跳过对开放票证的测试，从而允许构建通过。
但是：
新的约定是仅在修复bug时提交测试。
我建议你考虑一下WordPress放弃这种方法的原因（在那张罚单中有概述），我想你可能会得出结论，你不想这样做。相反，测试应该与修复一起提交。你不希望测试失败，你想要的是修复bug。
但这在回购协议中留下了数十个失败的测试。这些测试应该被拉出，转换成补丁，并上传到相关的Trac记录单上，并附上一个说明，说明刚刚发生了什么。一旦所有失败的测试退出回购，我们可以删除knownWPBug 测试运行程序的行为。
已完成此操作，但正在删除knownWPBug(). 可能是出于向后兼容性的考虑而决定保留它。
您仍然看到许多跳过的测试的原因是，一些测试要求打开（或关闭）多站点，而另一些测试要求在编译PHP时禁用某些扩展。跳过测试还有其他原因。