你如何说服别人写单元测试？

Question

我已经被测试感染了很长一段时间了，但似乎我与之合作的大多数开发人员从来没有尝试过或因为某种原因而解雇它，其中的论据通常是它增加了开销发展或他们不需要打扰。

最让我感到困扰的是，当我来对他们的代码进行更改时，我很难对其进行测试，因为我必须应用重构来使其可测试，有时最终不得不做很多的工作只是为了让我可以测试我即将编写的代码。

我想知道的是，您将使用什么参数来说服其他开发人员开始编写单元测试？我介绍过的大多数开发人员都非常了解它，看看它们带来的好处并继续使用它。这似乎总是好的开发人员，他们已经对提高代码质量感兴趣，因此可以看到单元测试如何做到这一点。

如何说服其他杂技团队？我不是在寻找测试好处列表，因为我已经知道这些是什么，但是您使用或将用于让其他人加入的技术。关于如何说服管理层发挥积极作用的提示也值得赞赏

Answer 1

质量不言而喻。如果你比其他人更成功，那就是你需要说的。

Answer 2

使用测试覆盖率工具。让它非常明显。这样每个人都可以轻松地看到每个区域中的代码通过，失败和未经测试。

然后你可以开始一种文化，其中“未经测试”是编码错误的标志，“失败”是正在进行的工作的标志，“通过”是完成代码的标志。

如果你也做“先测试”，这个效果最好。然后“未经测试”成为“你忘了第1步”。

当然，您不需要100％的测试覆盖率。但是，有一个区域的覆盖率为1％而另一个区域的覆盖率为30％，那么您就有一个度量标准，该区域最有可能在生产中失败。

Answer 3

我猜这个问题有不止一个方面。我发现实际上说服开发人员开始使用测试并不是那么难，因为使用测试的优势列表通常不言而喻。当说，实际上是一个很大的障碍，我发现学习曲线往往有点陡峭 - 特别是对于新手编码器。抛出测试框架，TDD测试优先心态，以及那些对C＃，。Net或一般编程都不熟悉的人的嘲讽框架，可能只是处理得太多了。

我是一名顾问，因此我经常要解决在组织中实施TDD的问题。幸运的是，当公司雇用我时，通常是因为我在某些领域的专业知识，因此在引起人们注意时我可能会有一些优势。或许这只是为了让我作为一个局外人进入一个新团队然后说“嗨！我在其他项目中尝试过TDD并且知道它有效！”或许这是我的说服力/顽固性？ :)无论哪种方式，我经常发现很难说服开发人员开始编写测试。我觉得很难，就是教他们如何编写好的单元测试。正如你在问题中指出的那样;留在正义的道路上。

但是我找到了一种方法，我认为在教学单元测试方面效果很好。我blogged about it here，但其实质是坐下来做一些配对编程。在进行结对编程时，我首先开始编写单元测试。这样我向他们展示了测试框架如何工作，如何构建测试以及经常使用模拟。单元测试应该很简单，因此即使对于初级开发人员来说，所有测试都应该相当容易理解。解释最糟糕的部分通常是模拟，但使用易于阅读的模拟框架（如Moq）有很大帮助。然后当编写测试（并且没有编译或通过）时，我将键盘交给我的同伴编码器，以便他可以实现功能。我只是告诉她/他; “让它变成绿色！”然后我们继续进行下一个测试;我编写测试，旁边的'即将被测试感染的开发者'写下了这个功能。

现在，重要的是要明白，在这一点上，您正在教授的开发人员可能还不相信这是正确的编码方式。大多数开发人员似乎看到（绿色）灯的点是由于某些代码更改导致测试失败，他们从未想过会破坏任何功能。当覆盖该功能的测试爆发时，那就是当你在团队中拥有忠诚的TDD时。或者这至少是我的经历，但一如既往;你的里程会有所不同：）

Answer 4

以身作则。如果您能够获得证据表明其他地方的单元测试代码的回归较少。

获得质量保证和管理层支持，以便您的流程要求进行单元测试。

随时准备帮助其他人开始进行单元测试：提供帮助，提供框架以便他们可以轻松启动，运行介绍性演示。

Answer 5

你必须习惯于口头禅“如果没有经过测试，工作就没有完成！”

编辑：为了在上面我的诙谐评论中添加更多内容，如果他们没有测试过他们的工作，怎么会知道他们是否真的已经完成了？

请注意，如果在测试devleoped代码的估计中不允许时间，那么你将有一场说服他人的战斗。

在编码和测试之间的一对一拆分似乎是一个很好的数字。

HTH

欢呼声，

罗布

Answer 6

赞美一个人写更多的测试并产生好的结果并向他人展示最好的结果，并要求他们产生与此相同或更好的结果。

Answer 7

两种方式：说服项目经理单元测试可以提高质量并节省总体时间，然后让他进行单元测试。

或者在重要的发布日期之前等待开发紧缩，每个人都必须加班加点和周末才能完成最后的功能并消除最后的错误，但却发现他们刚刚引入了更多的错误。然后指出，通过适当的单元测试，他们不必那样工作。

单元测试可以显示为必不可少的另一种情况是，实际发布了一个版本，并且由于最后一刻的更改而导致包含严重错误。

Answer 8

没有一个或多个痛点，人（和过程）不会改变。因此，您需要了解重要的痛点并演示单元测试如何帮助处理它们。

如果您找不到任何重大的痛点，那么单元测试可能不会为您当前的流程增加很多价值。

正如Steve Lott所暗示的那样，提供比其他团队成员更好的结果也会有所帮助。但没有痛点，我的经验是人们不会改变。

Answer 9

可能reefnet_alex的回答可以帮助您： Is Unit Testing worth the effort?

  

我认为是福勒说：   “不完美的测试，经常运行，是   比完美的测试要好得多   从来没有写过“。我   把它当作给我的   允许我在哪里写测试   认为他们即使是最有用的   我的其余代码覆盖范围是   可悲的是不完整。

Answer 10

如果开发人员看到“成功的”开发人员正在编写单元测试，而他们仍然没有这样做，那么我建议单元测试应该成为正式开发生命周期的一部分。

E.g。在编写和审查单元测试之前，无法检查任何内容。

Answer 11

您提到您的经理正在进行单元测试。如果是这样，那他为什么不执行呢？让别人跟进或教他们不是你的工作，事实上，如果你试图推动它们，其他开发人员会经常怨恨你。为了让您的开发人员编写单元测试，经理必须强调强烈。可能最终强调的部分重点是单元测试实施的教育，你可能最终成为教育工作者而且这很好，但管理它就是一切。

如果您处于小组决定实施方式的环境中，那么您对群组动态应该有多少发言权。如果你处于那种环境中并且小组不想在你做的时候强调单元测试，那么也许你是在错误的小组/公司。

Answer 12

我发现“福音传播”或讲道很少奏效。正如其他人所说的那样，按照自己的方式为自己的代码执行，让它知道你这样做，但不要试图强迫别人去做。如果人们问它是支持和有帮助的。提供一些午餐时间研讨会或非正式的狗和小马表演。这不仅仅是向你的经理或其他开发者抱怨你很难为他们编写的代码编写测试。

缓慢而稳定 - 一夜之间不会改变。

有一次我意识到，在我工作的一个地方，对同行评审的认可度大大提高了。我的小组刚刚做了，并且不再试图让其他人去做。最终人们开始询问我们如何取得一些成功。然后它更容易。

Answer 13

我们有一个测试框架，其中包括每当有人进行更改时自动运行测试套件。如果有人提交的代码未通过测试，则整个团队都会收到错误的电子邮件。

这导致引入的错误很快得到修复。