如何处理反对单位测试的同事

Question

在我们的Scrum团队中，有一些成员在没有单元测试的情况下将内容发送到页面，然后在代码中的其他地方进行更改时会抱怨他们的内容。副词总是“它曾经工作，你做了什么？”

我们很早就转向敏捷，CI是议程上的下一个议题之一。在那之前，我该如何处理人的问题？毕竟，这是最难对付的部分。

Answer 1

您是团队，所以在开始工作之前必须同意。没有协议责备游戏将永远持续下去（而且几乎任何事情都是如此）。

请参阅我对单元测试价值问题的回答： The Value of Unit Testing

Answer 2

我认为处理这类事情的最佳方式是通过问责制。如果他们的东西坏了，他们就会受热并且必须找到修复，即使根本原因在其他地方，问题的一部分是他们在释放之前没有抓住它。

请注意，这实际上并不能说服他们改变他们的习惯......

Answer 3

与他们交谈。问他们为什么不进行单元测试。如果它只是懒惰，请解释从长远来看如何节省时间（使用你提到的具体例子），是的，需要付出一些努力才能进入，但很快就会变成一种已经证明有益的习惯。

如果这没有帮助，请给他们一个单独的时间buget进行单元测试和实现，并告诉他们现在他们的工作花5个小时为这个用例生成单元测试报道，你会很乐意帮助他们开始。

如果仍然没有帮助，那就解雇他们，让那些不会忽视直接命令的人正确地完成他的工作。

Answer 4

在这里扮演魔鬼的拥护者，但为什么其他地方的变化会破坏他们的代码呢？单元测试是否真的可以防止这种破损？人们是否破坏或改变代码单元之间的接口？

我的意思是，单位测试和按合同设计是很棒的事情，但代码必须要遵守合同。让这些程序员编写单元测试将有助于确定何时出现问题，但是它是否能帮助您更好地预防这些问题？听起来可能存在需要解决的更大设计问题。

Answer 5

无需编写单元测试就打破构建的人需要为整个团队购买午餐。

Answer 6

我首先要看一下你的团队政策。为什么他们首先允许在没有单元测试的情况下提交代码？如果您需要一致的单元测试，则需要设置策略。您可以解释单元测试是回归问题的重要方法。如果他们继续抱怨，请指出该政策并告诉他们单位测试不是可选的。

Answer 7

使用具有良好指责机制的持续集成系统。像Hudson这样可以持续检查Subversion或其他源控制系统的东西。设置CI构建系统，以便在系统测试失败时立即发送电子邮件，以广播引入错误的名称和更改。

换句话说，确保每个人都知道谁在引入错误并在引入错误后立即识别错误。随着时间的推移，这些脾气暴躁的开发人员将意识到他们是引入缺陷的人。