脆弱的单元测试总是一件坏事吗？

有时我发现一个非常脆弱的测试是一件好事,因为当我改变测试代码的意图时,我想确保我的单元测试中断,以便我被迫重构...这种方法不推荐建立一大套回归测试？

单元测试必须是脆弱的 - 必须容易打破它们.如果它们没有破坏,那么它们根本就不是单元测试; 他们是代码评论.

...

或者我错过了问题的重点？

编辑:我应该澄清我之前的答案.

我对这门语言有点迂腐."脆弱"只是意味着"容易打破".单元测试应该很容易破解.术语"脆性测试"应该是" 过于强烈的测试"; 他们不应该打破的测试.即便如此,修复一个过于脆弱的测试比修复一个漏洞通过脆弱性测试的错误要容易得多,所以继续编写你的脆弱测试!

劝告脆弱单元测试的一般声明主要适用于尚未完全接受单元测试的商店.例如,当尝试从没有测试转换为完整的单元测试套件,或者当您的项目是单元测试试验项目时.在这些情况下,开发人员习惯于单元测试中的误报,并开始忽略它们.然后单元测试落后于生产代码,要么落后,要么需要大力更新.

我会说你应该总是针对你能够完全测试你的功能/模块的最不易的测试,但如果你有1或2个脆弱,你应该在大多数情况下都没问题.

IMO,只要您的测试确保您的应用程序代码执行它应该执行的操作,并且如果更改,测试失败,那么您的测试就可以了.你能用"脆弱"来定义你的意思吗？

只需确保您的测试真正涵盖了应用代码的各个方面.(在合理范围内).

正如营养不良者指出的那样,单元测试应该是脆弱的,因为它们容易破碎.但是,我想补充说,它们不应该是脆弱的,因为它们随机传递或失败.

在涉及线程和套接字的测试中会发生很多这种情况.测试应该使用互斥锁和其他"等待"设备,以避免测试在无法控制的情况下失败,例如高处理器负载.

随机脆弱测试的明确"气味"是在测试中使用sleep()函数.