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

我是一家中型公司的软件工程师。我们在TeamCity上运行着一个相当强大的测试平台。它会在每次签入时进行单元测试，并每天运行单元测试/ BVT。

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

通常，如果单元测试经常中断且无法维护，我会提出毫无意义的建议。无法查看更改是否引起了回归，从而消除了单元测试平台的大部分价值。

我想种下一种会养成良好习惯文化的种子-破坏测试时将其修复，将其视为有价值的东西，将测试的固定与其他工作一起放在优先位置。

我已经尝试过贿赂（烘焙食品！），只是简单地询问，并与团队负责人交谈。每个人都说这是一个好主意，但我认为这是唯一对此做任何事情的人。

鼓励他人修复测试并在冲刺中优先考虑修复的最佳方法是什么？

如果有比较主观的方式提出这个问题，我很乐意接受任何提示。

做到这一点，就不可能在不修复测试的情况下实际发布任何东西。

1. 如果任何测试失败，则使构建失败。
2. 如果忽略任何测试，则构建失败。
3. 如果测试覆盖率低于某个特定级别，则使构建失败（因此人们不能只是删除测试来解决该问题）。
4. 使用CI服务器进行发布构建，并且仅允许将服务器的构建放置中的构建提升为UAT /登台/生产/其他版本。

事实是，如果您的构建一次损坏超过15分钟（并且包括失败的测试），那么您就不会进行持续集成。

“核选项”是让您的源代码管理服务器拒绝破坏构建的用户以外的任何用户的提交/签入。显然，如果该人去度假，则管理员需要能够暂时改写此权限-但是，如果每个人都知道整个团队都被搞砸了，直到他们修复了测试，那么他们将很快解决这个问题。

一个好的策略（在自动执行时会更好）是在构建失败15分钟后将源恢复到最后一次已知的稳定提交。换句话说，如果您无法修复它，或者不知道是什么原因导致构建或测试中断，请还原它并在本地工作，直到解决为止-永远不要让其他开发人员在您不满意的时候打个招呼。他们不在乎的问题。

PS：如果您已经有很多测试失败，则可以在CI中使用“跟踪阈值”。设置它，这样如果有生成唯一的失败更多的测试失败不是最后一次。如果再加上覆盖规则，那么如果开发人员希望能够继续工作，他们最终将不得不改善测试情况。

PPS我意识到这在某些情况下可能看起来很苛刻，但这完全取决于您的文化。如果您达到了人们不会让构建崩溃或测试失败的地步（我的团队几乎从来没有做到过，尽管有时我不得不提醒他们），那么您就不必继续遵循最严格的规则了。尽管是IMO，但您应该始终在损坏的单元测试上使构建失败。集成/浏览器测试有时可能会失败。

失败的单元测试不是问题。他们是一个症状。

真正的问题在于文化。您需要轻踩一下：这里是龙。您无法独自改变文化，而吱吱作响的车轮最终将使您被淘汰。从字面上看。

我建议，如果您尝试寻找一位资深人士来捍卫事业并引领潮流。如果失败，请尝试在一般开发人员会议上提出，不要用手指指或叫名字。另一种选择是让您自己负责做正确的工作：每次签入时仅修复一些测试。在墙上保留一张图表，显示一段时间内有多少测试失败。其他人会看到的：也许他们会选择加入。

没有简单的答案。