如何激励同事编写单元测试？

Question

我们正在研制一种已经生产了大约5年的大型产品。代码基是..。呃..。工作中。不太好，但正在起作用。新特性被投入到生产中，并通过一个小的QA进行测试。Bug是固定的，等等。但是除了我之外，没有人在写单元测试。没有人会通过编写单元测试来“跟踪”bug，以确保这个特殊的bug(测试用例)永远不会再次发生。

我和管理层谈过了。我和开发人员谈过了。我和整个公司的每个人都谈过了。每个人都说：“是的，我们必须写更多的单元测试！”那是一年前的事了。从那时起，我就强制引入预提交代码检查(格瑞特)和持续集成(詹金斯)。

我举行了一些关于单元测试的会议，我也展示了编写单元测试的好处。但似乎没人感兴趣。

Q1:如何激励我的同事编写单元测试？

Q2:我如何保持动力来遵守我的个人代码质量标准？(有时S真的很沮丧！)

PS:一些令人沮丧的事实(在一年内达成)：

• 单元测试总数: 1693
• 总计“示例单元-测试”：约50
• 由我决定: 1521

编辑:我期望太多了吗？这是我的第一份工作，我正在尽我最大的努力。

编辑2:在所有答案的基础上，我为自己做了一个小清单。我和两位开发人员私下谈过了，我们进行了一次愉快而坦诚的交谈。

其中一个人告诉我，就像特拉斯廷说的，他对单元测试感到非常不舒服。他说他想变得“更专业”，但他需要一个新的开始。他还说，我们与所有开发人员的单元测试会议(9-11左右)很好，但太拥挤了。嗯。对我有些批评，但我会从中吸取教训的。(见下文关于tdd kata会议的答案！)

另一个说他对编写单元测试不感兴趣。他认为他的工作足以支付他的工资。他不想投入更多的精力。我说不出话来。典型的9-5“工人”。

下个星期我要和其他开发人员谈谈。

谢谢你的伟大回答(到目前为止！)还有你的支持。我真的很感激！我学到了很多，非常感谢！

Answer 1

我注意到谈论TDD几乎不起作用。人们喜欢看到原始的结果。说“编写测试将缩短开发时间”很有可能是真的，但这可能不足以让人信服。

我处于类似的状态(嗯，没有你的糟糕)，当人们开始处理我的代码时，它就解决了(注意:我的代码是经过单元测试的，其他人没有那么多)。当某件事停止工作时，当地调查后的自然跟进就是问我原因是什么。然后我们坐下来，进行单元测试，看看发生了什么。如果测试通过，大多数情况下问题都出现在新的、未经测试的代码中。如果没有，测试通常能够发现问题(或者至少指出正确的方向)。我们修好了窃听器，测试又开始了，大家都很高兴。

长话短说，像这样的一些情况发生了变化，又有2个开发人员成为了TDD/测试爱好者(还有几个人要去做，但看起来很有希望)。

至于建议，您可以使用TDD kata；使用测试优先方法(而不是不进行测试)来实现简单的任务。根据任务的复杂程度，非测试方法通常应该更慢，特别是在需要进行增量更改的情况下：

• 罗伊(氏)串计算器
• 银行OCR

编辑:OP的评论让我意识到，还有更强大的论据可供他使用--回归，也就是返回错误。这些情况都是很好的例子，展示了单元测试是多么有益。喜欢数字的人--就像我说过的，告诉“单元测试是好的”--可能没有说服力，但是像下面这样排列数据肯定是：

• 实现特性所花费的时间(没有编写测试；我假设这种情况经常发生，所以应该比较容易找到这样的例子)。
• 估计使用TDD实现特性的时间(甚至在接近之后进行测试；无关紧要--重要的是单元测试的存在)
• 用于解决未经测试的vs测试代码上的错误的时间

有一件事要提醒您(这个问题很明显，但值得注意)：结果偏倚 --确保您没有选择使用测试发现bug的唯一方法是为该bug编写测试的示例。通常，没有人知道bug会提前发生，但很容易说“如果我们对X进行测试，这个bug将是微不足道的”--在战争结束后很容易找到一种获胜的策略。

这些例子的结果应该是一个简单的问题--如果你可以花x小时开发特性Y，为什么要坚持在2x中这样做呢？

Answer 2

首先，你必须知道他们为什么不写测试。

严格的开发计划往往是原因，但你说你没有。

下一个原因是，由于现有大量未经测试的代码库，编写测试可能会让人望而却步--这是一项永无止境的工作(比如洗衣房之类的工作，也同样令人兴奋)。所以人性是认为这是太多的面对，所以我会跳过它。

另一个原因可能是，虽然他们认为测试是个好主意，但他们对如何开始编写测试没有信心，尤其是如果他们从未在任何地方写过测试。

另一个很强的可能性是因为他们认为更多的工作没有任何价值，尽管他们只是口头上支持这个想法。

那么，你如何处理不同的原因呢？

原因之一很简单，给他们一个例子，说明它如何节省开发时间。

第二个原因--向他们展示你一年编写的测试数量，以及它涵盖的代码库的百分比。做个数学题，看看明年这个时候如果他们这么做，还可以进行多少次测试。一旦他们看到每天的一点点进步真的累积起来，整个想法就不会那么令人难以抗拒了。如果您可以将数据从系统中提取出来，请向他们展示代码中未经过测试的部分中有多少bug是重复的，以及有多少重复的bug出现在代码中并带有单元测试。

第三条理由是训练，而不仅仅是展示。让他们在训练班写测试。

第四，这是问题的症结所在。首先，选择一个痛点，其中一个bug已经多次返回。当出现这种情况时，现在是向管理层建议的时候了，如果他们对这个项目进行了单元测试，它就不会再像一个坏便士一样回来了。

另一种解决原因4的方法是让管理层将其作为流程的一部分，除非测试也通过代码评审，否则代码不会通过代码评审。最好是在这些疼痛点之后，或者最好是在你几天之内有过几次之后，把这作为一项政策来对待他们。

我们都喜欢认为，作为开发人员，我们自己管理(LOL)，但雄心勃勃的人会关心管理强调他们应该关心的，而真正做自我管理的专业人士已经在编写测试。如果他们不关心专业和做最好的实践，因为他们改善了产品，或关心如何给经理留下印象，以获得晋升(或不被解雇)，那么你可能会考虑这是否是适合你的地方。如果你不能让管理层关心最佳实践，那么你将一路上都在进行一场艰难的战斗，你可能会评估这是否是适合你的企业文化。虽然每个工作场所都有自己的问题(逃跑并不总是解决问题的办法)，但这个地方似乎不符合你的专业水平。

Answer 3

首先，我将展示TDD的好处。试着展示单元测试的好处。

作为正常人，开发者的动机是利益。他们不想做的事情只是创造更多的工作。单元测试意味着较少的工作量。这意味着多和朋友出去。这意味着有更多的乐趣，因为你不必在晚上11点之前每天晚上编码。这意味着更多的是带着平静的心情去度假。

TDD最大的好处之一是，您可以将程序重构为更好的设计，或者只需更改某物的名称。只要这个设计没有破坏测试，你就可以百分之百地相信你的改变并没有破坏任何东西。

TDD的另一个很好的例子是为遗留代码创建单元测试。这将是开始重建邪恶的最好方式之一。从长远来看，这将有助于提高您对代码库的了解，了解其优点和缺陷，在代码中发现硬编码业务逻辑，并给您一个良好的开始，以提高质量前进！

供进一步阅读的良好参考资料：

• 为什么要写单元测试
• 动机可见性和单元测试
• 罗伊说，单元测试的艺术