如何激励同事编写单元测试？[关闭]

我们正在研究已经生产大约5年的大型产品。该代码库在工作。效果不是很好，但是可以正常工作。新功能投入生产并通过少量质量检查进行了测试。错误已修复，等等。但是除我以外，没有人在编写单元测试。没有人通过编写单元测试来确保所有特殊错误（测试用例）再也不会发生，从而利用“跟踪”错误的能力。

我已经和管理层谈过了。我已经和开发人员谈过了。我已经与整个公司的所有人进行了交谈。每个人都说：“是的，我们必须编写更多的单元测试！” 那是大约一年前。从那时起，我就开始引入预提交代码审查（Gerrit）和持续集成（Jenkins）。

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

问题1：如何激励我的同事编写单元测试？

问题2：如何保持动力以遵循我的个人代码质量标准？（有时真的很令人沮丧！）

PS：一些令人沮丧的事实（在1年内达成）：

• 单元测试总数：1693
• 总“示例单元测试”：大约50
• 由我完成：1521

编辑：我期望太多了吗？这是我的第一个工作地点，我正在努力做到最好。

编辑2：根据所有答案，我为自己做了一个小清单。我已经与两位开发人员私下交谈过，我们进行了坦诚交谈。

其中一位告诉我，就像Telastyn所说的那样，他对单元测试真的很不满意。他说他想变得“更专业”，但是他需要一个启动。他还说，我们与所有开发人员（9-11岁左右）进行的单元测试会议很好，但是太拥挤了。嗯 一些批评家给我，但我会从中学到东西。（请参阅以下有关tdd kata会议的回答！）

另一位表示他对编写单元测试不感兴趣。他认为自己的工作足以应付他的薪水。他不想付出更多的努力。我非常无语。典型的9-5岁的“工人”。

下周，我将与其他开发人员交谈。

感谢您的出色回答（到目前为止！）和支持。我真的很感激！我学到了很多东西，非常感谢！

我注意到谈论TDD几乎没有用。人们喜欢看到原始结果。说“编写测试将减少开发时间”很可能是对的，但是这不足以使任何人信服。

我处于类似的位置（嗯，还不如你的糟糕），当人们开始使用我的代码时，它可以自行解决（注意：我的代码已经过单元测试，其他人并没有那么多）。当某事停止工作时，经过当地调查自然会跟我问可能是什么原因。然后我们坐下来，进行单元测试，看看发生了什么。如果测试通过，则大多数时候问题出在未经测试的新代码中。如果没有，测试通常能够发现问题（或至少将我们指向正确的方向）。我们修复了该错误，再次进行了测试，每个人都很高兴。

长话短说，出现了这种情况，还有2个开发人员成为了TDD /测试爱好者（还有很多工作要做，但看起来很有希望）。

至于建议，您可以尝试一下TDD kata。使用测试优先的方法来实现简单的任务，而不需要测试。根据任务的复杂程度，非测试方法通常应较慢，尤其是在需要进行增量更改时：

• 罗伊的字符串计算器
• 银行OCR

编辑：OP的评论使我意识到，在他的支配下还有更强的论据- 回归也就是返回错误。此类情况是证明有益的单元测试的完美示例。人们喜欢数字-就像我说的那样，告诉“单元测试是好的”可能并不令人信服，但是像下面这样排列数据肯定可以：

• 实现功能所花费的时间（未编写测试；我认为这种情况经常发生，因此找到这样的示例应该相对容易）
• 用TDD实施功能所需的估计时间（甚至在方法之后进行测试；无所谓-重要的是存在单元测试）
• 解决未经测试的代码与经过测试的代码上的错误所花费的时间

要警告您的一件事（此错误很明显，但值得注意）：结果偏向 -确保您没有选择仅通过测试发现bug的方法就是编写该bug的示例。通常，没有人知道错误会提前发生，但是很容易说“如果我们对X进行测试，这个错误将是微不足道的” -很容易在战争结束后为战争找到成功的策略。

这些示例的结果应该是一个简单的问题-如果您可以花x个小时的时间来开发特征Y，为什么要坚持以2 倍的速度进行呢？

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

严格的开发计划通常是原因，但您却说没有。

另一个原因是，由于现有的未经测试的代码库很大，编写测试似乎势不可挡-一项永无止境的工作（例如洗衣服和令人兴奋的事情）。因此，人类本性是要面对太多的事情，因此我将其跳过。

另一个原因可能是，尽管他们认为测试是一个好主意，但他们对如何开始编写它们并不自信，特别是如果他们从未在编写过这些代码的地方工作过。

另一个强大的可能性是，即使他们为这个想法提供了口头服务，他们实际上并没有看到更多工作的任何价值。

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

原因很简单，请向他们展示如何节省开发时间的示例。

原因二-向他们显示您一年编写了多少个测试，以及测试涵盖的代码库百分比。做数学运算以显示如果他们这样做的话，明年此时他们可以进行多少测试。一旦他们每天看到一点点进展真正加起来，整个想法就不会那么令人沮丧。如果您可以将数据从系统中拉出，请向他们显示代码未测试部分中有多少错误是重复错误，以及使用单元测试在代码中出现了多少重复错误。

原因3是培训，而不仅仅是展示。让他们在培训课上写测试。

原因4，这是问题的症结所在。首先，选择一个痛点，这是多次返回的错误之一。当出现这种情况时，现在是时候向管理层建议，如果他们对此项目进行了单元测试，它就不会像坏钱一样不断回来。

解决原因4的另一种方法是让管理层将其纳入流程的一部分，并且除非测试也通过代码审查，否则代码不会通过代码审查。最好在这些痛点之一之后，或者最好在几天之内遇到几个痛点之后立即制定这项政策。

我们所有人都喜欢认为，作为开发人员，我们要进行自我管理（LOL），但是雄心勃勃的人会在意管理对他们强调的一点，即他们应该关注的事情，真正从事自我管理的专业人员已经在编写测试。如果他们既不因为提高产品质量而在意专业和最佳实践，也不在乎如何打动经理人而获得晋升（或不被解雇），那么您可能会考虑这是否是适合您的地方。如果您无法让管理层关注最佳实践，那么您将一路艰苦奋斗，您可能会评估这是否适合您的企业文化。尽管每个工作场所都有其问题（逃跑并不总是答案），但这个场所似乎并不适合您的专业水平。

我将从演示TDD的好处开始。尝试展示单元测试的好处。

作为普通人，开发人员受收益激励。他们不想做只会增加工作量的事情。单元测试意味着更少的工作。这意味着更多地和朋友出去。这意味着要有更多的乐趣，因为您不必在晚上11点之前花所有时间编码。这意味着您可以放心地去度假。

TDD的最大好处之一是，您可以将程序重构为更好的设计，或者只是更改名称...只要设计不破坏测试，您就可以100％确信所做的更改没有破坏任何东西。

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

很好的参考，可供进一步阅读：

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

http://blog.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first

我想我在一段时间前把Jeff Atwood文章中的链接标记为书签[编辑：是，这里是]。古老但相关。由于这些好处以及在其他答案中无疑会概述的其他好处，您的程序员应该能够激励自己！这将使他们的工作效率更高，从而使他们的工作更轻松。谁不想要那个？

关于第二个问题：您的主人翁意识和对代码质量标准的自豪感应该使您与之保持一致。考虑一下您想通过拥有这样的标准来实现什么以及谁将从中受益。我的个人代码标准也可能令人沮丧，但是我始终觉得自己正在通过实施这些规范来帮助世界/公司/团队。因此，我认为您并没有尝试做太多的事情-结果因地方而异，但至少您正在努力。

这似乎是一个很好的榜样。

您正在与人性作斗争的两个固有方面：

• 有创造力的人不喜欢过程。
• 大多数人不喜欢外界对其质量的负面评价。

很难通过演讲，管理声明甚至逻辑来与之抗衡。您必须赢取利用人性的另一个方面的优势。

• 人们模仿最好的员工的行为

如果最优秀的员工使用TDD并能奏效，则流程将扩大。如果他们不这样做，那就不会。如果您需要说服任何人，那就是前1名或2名员工。

问他们。

您说人们已经被告知，并同意他们应该编写更多测试。他们为什么不呢？

可能不是（通常不是）简单的动机问题。他们可能会忘记他们。他们可能会感到时间紧迫。他们可能不知道如何编写好的测试。他们可能会认为您太好了，他们不需要这样做。了解根本原因将帮助您更好地解决问题。

您可能会认为单元测试本身就是销售。我不知道您的公司如何运作，但是在生产推广期间出现问题时，我们会一直进行直到解决。周日凌晨2点是否发生都无关紧要。这对我们来说是非常罕见的，但是一旦这样做，它就糟透了。

首先，我要问他们半夜起床几次，以解决一些很容易被自动化测试发现的重大问题。这并不是说自动测试可以解决所有问题，但是应该可以帮助减少故障。

第二大卖主是质量检查周期。在我公司开始开发TDD之前，我们将每周对新版本进行质量检查。他们会从该发行版中产生大量错误，我们将修复这些错误并推出另一个发行版。重复直到完成。我们进行TDD的第一个项目直到几周后才需要进行质量检查。发现的错误数量非常非常小。与类似项目相比，降低了10％。您是否有必要为您的团队编制这些统计数据？

另一个大卖点是在采用TDD后代码看起来如何，更易于阅读，因为我们希望使测试更容易。显示为单元测试编写的代码与未编写的代码之间的比较。

最后，向他们展示他们将如何自信地重构代码。

当您不想编写测试时，请记住所有这些。:)

我想详细介绍HLGEM的答案，特别是以下部分：

另一个原因是，由于现有的未经测试的代码库很大，编写测试似乎势不可挡-一项永无止境的工作（例如洗衣服和令人兴奋的事情）。因此，人类本性是要面对太多的事情，因此我将其跳过。

我发现，我打算写测试的代码要比不写测试的代码好得多。问自己如何测试此功能？强制对每个功能进行更好的设计。（较少依赖全局或半全局数据； IO与计算分离；功能仅做一件事；一致的错误处理；等等。）

试图对未考虑测试编写的旧代码进行测试可能会令人沮丧。

我使用了一些技巧：

a）设置一个自动构建。当某人破坏了您测试的内容时，请向他们展示测试如何检测到该错误以及该错误的严重程度。

b）进行带有测试的复杂项目（您自己开车）。这将显示该项目中几乎没有错误。我有一个复杂的服务器交互项目，它开始正常运行。它从未失败过质量检查，所有集成测试都顺利进行了100％。该系统被称为高度稳定，并且整体管理对此感到满意。在这些情况下，您可以做的事情是如何通过单元测试实现的。

c）一次拉一个人。听你的那个人。试一试错误，并说明测试如何揭示深层而棘手的问题。这会有所帮助。这绝非易事。但是一旦获得粉丝，他只会帮上忙。这是多米诺骨牌效应。

在此过程中进行单元测试。如果生产中出现的错误太明显而无法进行单元测试，那么这家伙就应该承担责任。指派人员编写他们进行的每个测试。每周随机挑选案例并观察少数案例的执行情况。通过进行单元测试，人们将询问需求，并最终将需求与开发联系起来，并希望开发既可运行又可运行的软件：）