我在编写测试以重现尚未修复的问题的方式上有点挣扎。
是否应该编写测试并使用错误的期望，一旦错误被修复，开发人员将看到失败并调整期望，或者应该只使用正确的期望编写测试并禁用它。修复后，您必须再次启用它。
我更喜欢定义错误期望并在 cmets 中添加正确期望的方式，一旦我解决了问题，我会立即收到失败的通知。如果我禁用它，我不会看到它失败，并且它可能会一直禁用，直到人们发现这个测试。
还有其他方法吗？
感谢您的 cmets。
马丁
【问题讨论】：
标签： testing regression
理想情况下，您会编写一个重现该错误的测试，然后修复该错误。
如果出于某种原因，目前这不是一个选项，我会说你有错误期望的方法比忽略测试要好。假设您使用一些明确的变量名称/方法名称/cmets，测试更多的是占位符而不是预期的结果。
我做过的一件事是写了一个测试，它是一个“定时炸弹”提醒。我选择一个几周/几个月后的日期，我希望能够回到它或修复它。如果我最终不得不将日期推迟 2 或 3 次，我最终会删除测试，因为它一定没那么重要。
【讨论】：
正如@Jarred 所说，最好的方法是编写一个表达正确期望的测试，检查它是否失败，然后修复生产代码并查看测试通过。
如果这不是一个选项，那么请记住，测试不仅是为了测试，也是为了记录。所以写一个测试来记录你的程序是如何实际工作的。如有必要，请在测试中添加评论。并且不要编写被忽略的测试 - 这是没有意义的。将来你可以多次重构你的代码，你可能会不小心修复这个测试或者在这个区域引入更多的错误。编写打算长期忽略的测试只是浪费时间。
不要担心您会忘记那个特定的错误/测试，只需在您的问题跟踪系统中创建一个工单 - 这就是它的用途。
如果您使用支持组的测试框架，您可以添加所有这些测试，以便能够在需要时立即排除这些测试。
我也真的不喜欢“定时炸弹测试”的概念。您的构建必须是可重现的——这是发布管理、持续集成、将代码传递给另一个团队的能力等的基本假设。测试并不是为了跟踪和提醒问题，而是问题跟踪系统的工作。说真的，不要这样做
【讨论】：
其实我又想到了这个。我们正在使用 JUnit，它支持通过 @Test(expected=Exception.class) 定义对异常的期望。
所以可以做的是用期望的期望编写测试并使用@Test(expected=AssertionError.class) 定义测试。修复测试后，测试开始失败，开发人员必须消除期望。
【讨论】：