如何创建一个将修复测试视为优先事项的环境？

Question

我是一家中型公司的软件工程师。我们有一个运行在TeamCity上的相当健壮的测试平台。它对每个签入都进行单元测试，并每天运行单元测试/BVT。

问题是-我们有很多坏的单元测试。

很多时候，如果单元测试不断中断和无法维护，我就会提到它们的无意义。由于无法查看更改是否导致了回归，因此删除了单元测试平台的大部分值。

我想要种下一种种子，创造一种良好习惯的文化--在测试被打破时修正它们，将它们视为有价值的，并将修复测试和其他工作放在优先位置。

我试过贿赂(烤面包！)，只是简单的询问，并与团队领导交谈。每个人都说这是个好主意，但我看到只有我一个人在做任何事情。

什么是最好的方法来开始鼓励其他人修复他们的测试，并在他们的sprint中确定测试修复的优先级？

如果有一种不那么主观的方式来问这个问题，我很乐意接受任何建议。

Answer 1

如果不修复测试，就不可能真正发布任何内容。

1. 如果任何测试失败，请失败构建。
2. 如果忽略任何测试，则失败构建。
3. 如果测试覆盖率低于某一级别，则失败构建(因此，人们不能仅仅删除测试来绕过它)。
4. 使用CI服务器进行发布构建，并且只允许将服务器构建拖放中的构建提升到UAT/暂存/生产/任何其他版本。

事实是，如果您的构建一次中断超过15分钟(这包括失败的测试)，那么您就不会进行持续的集成。

“核选项”是让您的源代码管理服务器拒绝来自任何用户的提交/签入，而不是破坏构建的用户。显然，管理员需要能够暂时覆盖这一点，如果该人去度假-但是，如果每个人都知道整个团队是失败的，直到他们修复他们的测试，那么他们会很快解决。

一个好的策略(当它是自动化的时候更好)是在构建失败15分钟后将源恢复到最后一个已知的稳定提交。换句话说，如果您无法修复它，或者不知道是什么导致了构建或测试崩溃，那么就还原它并在本地工作，直到它解决为止--永远不要让其他开发人员在处理他们不关心的问题的时候绞尽脑汁。

如果你已经有很多测试失败，你可以在CI中使用一个“尾随阈值”。设置它，以便只有当测试失败比上次多时，构建才会失败。这与覆盖规则一起，将迫使开发人员最终改进测试情况，如果他们想继续工作的话。

我知道这对某些人来说可能很严厉，但这都是你的文化。如果您到了这样的程度:人们不会让构建失败或测试失败(我的团队几乎从来没有这样做，尽管我偶尔不得不提醒他们)，那么您就不需要继续使用最严格的规则集了。虽然国际海事组织，你应该总是失败的建设在一个破碎的单元测试。集成/浏览器测试有时可能失败。

Answer 2

失败的单元测试不是问题所在。它们是一种症状。

真正的问题在于文化。你需要轻轻地踩:这是龙。你自己不可能改变文化，成为一个吱吱作响的车轮最终会让你成为一个被抛弃的人。从字面上看。

我建议，如果你试图找一个资深的人来支持这一事业，并引领前进的道路。如果这样做失败了，尝试在一般的开发人员会议上提高它，而不指指点点或呼喊名字。另一种选择是自己负责做一项正确的工作:每次签入时只需修复更多的测试即可。在墙上保留一张图表，显示有多少测试随着时间的推移而失败。其他人会看到:也许他们会选择加入。

没有简单的答案。