是什么促使或说服开发人员编写单元测试？
我希望这个问题是通用的，但是，如果需要一些上下文，可以在这里我们的故事：
我们有几个JS UI开发人员根本不编写单元测试
-我们尝试通过额外的手动和自动端到端UI进行补偿
测试（我们基本上将此金字塔上下颠倒了）。他们的理由是，我们有很多需要满足的直接客户
需求-无法承受额外的测试时间。
#1 楼
首先要说明开发人员要认真对待自己的学科。他们应该遵循程序员的誓言。我将在每个版本中提供一个快速，确定且可重复的证明
，证明代码的每个元素都可以正常工作。
我喜欢UncleBob如何将开发软件与会计和医学洗手等学科的双重记账进行比较。数十年来在其受人尊敬的领域中皱眉的事物。现在，这些实践已由法律强制执行。
单元测试不适合用户，不适合测试人员，不适合管理人员，不适合构建系统，但不适合开发人员！当他们消除对改变的恐惧。消除对变更的恐惧，可以进行重构。重构是保持软件可维护和可扩展的第一技能。这就是每个开发人员都希望他们的同事编写经过单元测试良好的，经过解耦的代码的原因。
通过编码dojo来教四种TDD技能：
使用测试用例进行开发
设计测试用例
安全重构
设计干净的代码
Codo dojo的预习练习着重于训练这些技能，并且非常有用。一群有趣的待办事项。没有良好重构技能的单元测试并不好玩。阅读有关#NoTDD的文章，该文章没有解释TDD，但重构是此实践中的关键。
与开发团队一起观察Clean Code的基础知识。它包含了TDD上的两个精彩片段，他一直在展示为什么单元测试是敏捷软件开发中的关键。我们每次迭代观看一个情节，开发人员喜欢它。
单元测试通常被认为是一种负担，并不令人振奋
最后的测试很无聊，在代码很无聊之后编写单元测试。在过程结束时，您可能会感到有些压力。因此，在过程结束时填充通常是可选的。测试不是可选的。这就是为什么在编写任何代码之前都应该这样做的原因。 :)
我想说一下make，但我想激励您的开发人员阅读CleanCode书。如果那不能说服某人写单元测试，那就比什么都没有。
评论
+1如果您不进行测试就进行重构，而与进行测试相比，您可能会“感觉”到这种差异。我当然有
–迈克尔·杜兰特（Michael Durrant）
17年7月1日在9:44
如果您知道一家商店，测试人员会“向开发人员解释认真对待的纪律”，请告诉我。开发人员应该从经理那里得到指导和指导。您可以支持这些工作，但不能成为发起人。
–迈克尔·杜兰特（Michael Durrant）
17年7月5日在18:07
经理们不知道，他们经常专注于速度和速度，而不是质量。测试人员应加强工作，并对质量负责，并确保产品不会抵抗变化。 “软件的次要价值是其行为。软件容忍和促进这种持续变化的能力是软件的主要价值。软件的主要价值在于软件的软性。” -UncleBobseasidetesting.com/2013/03/12/…
– Niels van Reijmersdal
17年7月5日在20:45
支持我的书中的这些努力意味着使每个人都意识到。在每个人都知道之后，您可以支持他们。质量是整个团队的方法，不仅仅是管理人员，不仅仅是开发人员，也不只是测试人员。它与商店无关，它与测试人员的积极性有关。认为您排名第二意味着您排名第二。从反应性（不是我的工作）的思想来控制产品的质量并不是一件容易的事，但是真正尝试让它创建想要工作的商店并不认为您会在其他地方找到理想的商店。
– Niels van Reijmersdal
17年7月5日在20:51
@MichaelDurrant不幸的是，我已经工作了好几次，这已经是相当丰富的经验了……我最终实现了流程自动化以减少测试负担，然后获得了更多的测试时间，这使开发团队陷入了由于不断进行测试削减而未发现的错误的困扰。以前，但是可悲的是，管理层认为他们需要开发人员每周工作50个小时以上，而不是确定需要更改流程以产生质量更高的代码。他们肯定在那里...
– Mutt
17年7月8日在7:33
#2 楼
与e2e测试相比，单元测试在检测错误的根本原因方面要优越得多。也许我很幸运，但是我们的开发人员对添加单元测试抱有虔诚的态度-因为他们体验到它可以帮助他们更快地发现错误并允许重构。当e2e测试报告问题时，您必须调查出了什么问题。单元测试可以准确地告诉您出了什么问题，因此甚至可以大大缩短调查部分。
这是一个文化问题和管理问题。
您最近是否遇到过功能退化的问题？在进行事后分析时，很明显的建议是添加自动测试来检查条件。
自动单元测试是第一道防线。在许多测试专家看来，除非您有全面的单元测试，否则您甚至不会考虑开始编写e2e测试。
#3 楼
具体来说，测试人员如何激励开发人员？这实际上是一个难题。尤其是动机。有关该特定部分的一些建议：
批评代码而不是写代码的人
成为一个随和而有趣的灵活的人来与之共事
发展良好与编程经理的关系
对测试及其热情充满热情
共进午餐，并学习测试，TDD，BDD及其好处
与管理层合作，根据人们对哪些标准进行审查
参加应用程序代码审查，所以是一条两条路。
更一般的是：
教TDD
不是“代码应该在某个时候被测试覆盖...版本”，但是
编写失败的测试
编写代码以使其通过
版本..
还有三个关键要素：文化，重构和奖励（$）
文化：
关于测试，单元测试，测试编写，测试良好实践，何时编写功能性ui测试，如何管理测试的重叠等。
重构：
正如尼尔斯指出的那样，能够“安全地”重构是一件奇妙而令人惊奇的事情。它是文化的一部分，但值得一试！我最近写了一堆bash脚本，最后写了一个小的测试框架，只是为了重构它们。进行重构并像我一样进行那些测试的能力非常宝贵。同样，更改它们的想法（无论是重构，新功能还是错误）也非常令人恐惧。我想我已经开始参加测试了：)
奖励（$）：
确保测试是开发人员员工评估和工资增长的一部分。
如果您有旧的/遗留的代码* 1，请测量当前已测试的内容* 2，并创建一个项目来填充漏洞/未经测试的应用程序代码。如果代码是较旧的技术且没有测试，请考虑使用较新的测试。
* 1我所看到的遗留代码的最佳定义是“您今天在生产中使用的代码”
* 2使用代码覆盖率度量工具，例如codecov，代码环境等。
评论
我会说教重构，开发人员将开始更加重视TDD，单元测试和测试覆盖率。它与测试无关，而与无忧地更改您的代码（以及其他代码）有关。生成的代码具有可读性，可维护性，可测试性和可扩展性。
– Niels van Reijmersdal
17年6月30日在18:28
是!好点，我加了。
–迈克尔·杜兰特（Michael Durrant）
17年7月1日在12:45
#4 楼
单元测试更好地隔离了失败的根本原因（正如Peter Masiar在他的回答中指出的那样）。与端到端测试相比，它们也更可靠，更快。 Google的Mike Waker解释说，“只是拒绝更多的端到端测试”中有很多示例。关于保持端到端稳定的难易程度（因而花费很大），还有许多行业研究。例如，请参见Microsoft的Wayne Matthias Roseberry的“用易变的测试自动化赢得胜利”。我们在团队中注意到了类似的问题。同样，您也是如此，与单元和组件测试相比，我们在某些领域进行了太多的端到端测试。在某些时候，我们制定了一项政策，仅在100％的端到端测试通过时才关闭用户故事，但是由于端到端测试非常不稳定，因此我们的故事排队等待绿色测试的队列很长。这使开发人员大吃一惊，他们决定帮助我们将端到端测试的一部分移至单元/组件级测试。这只是处理不稳定测试的解决方案的一部分，但是通过两种方式解决了该问题。首先，从技术上讲，它限制了不稳定测试的数量。其次，开发人员更多地参与了测试，而我们更多地参与了单元/组件级测试。
#5 楼
我使用两种方法来激励开发人员编写单元测试：最好的开发人员，即受到高度认可的开发人员，以一种可行的方式解决了最棘手的技术问题。他们的解决方案是高质量和防弹的。达到顶峰的开发人员是那些也花费大量时间来测试自己的代码以删除项目符号的开发人员。遵守进度表可能被项目经理认为是一件好事，但是始终如一地交付高质量的优质软件将引起高层领导的注意。
其次，说明单元测试如何适合整体测试方案。 UI和API测试通常会测试路径是否令人满意，或者是否可以通过使用的数据注入故障。它很难/不可能到达处理错误/异常的代码。但是，单元测试可以完全控制模拟环境。使用单元测试，可以模拟慢速网络；有可能测试从属对象为null时会发生什么。
单元测试的另一个好处是，您的应用程序的业务逻辑可以非常快速，全面地进行测试，并且几乎没有误报。通常，依靠UI驱动的测试来验证“数学”将导致许多错误错误（不稳定的测试）。
#6 楼
是什么促使或说服开发人员编写单元测试？理想情况下，最令人信服的证据可能是统计比较；如果您可以比较两个相似的项目，一个带有单元测试，而另一个没有单元测试；尽管从一开始就需要花费更多的时间和精力来开发单元测试，但是具有单元测试的项目在长期维护上应该花费更少的资源，因此具有更高的商业价值。
但是我想每个人理论上都知道这一点;激励开发人员编写单元测试的实际方法是教育管理层，需要尽快而不是稍后才需要单元测试。
在实践中，我怀疑有人会说服开发人员编写测试用例，因为忽略了甜言蜜语不会带来任何后果。激励或说服开发人员的唯一方法是施加管理压力。经理将不跟他们说话，而是为单元测试创建任务。
作为测试人员，如果允许的话，请考虑与开发人员的经理聊天，并说服他（她）进行单元测试；只有这样，写作单元测试才能得到有效的加强。
评论
强迫人们编写单元测试的经理！真？您知道那些被迫编写测试的人如何制作测试吗？观看视频TDD并不是我们的意思，因为它有一些很好的示例测试，这些测试在晚上让我感到恐惧。 vimeo.com/83960706
– Niels van Reijmersdal
17年6月30日在18:23
@NielsvanReijmersdal，我想您是在选择“力”这个词。
–张瑜
17年6月30日在18:26
我选择了“激励或说服开发人员的唯一方法就是施加管理压力”。这是错误的，不是这个时代，它会导致错误的动机。但是当我生活在一种几乎没有等级制度和很多自组织的文化中时，我可能会感到有偏见。但是这些话不合我这个世界的范式，这让我很受伤。我能理解您的意见，但我认为我们不应该在这样的公共网站上倡导他们。抱歉。
– Niels van Reijmersdal
17年6月30日在18:34
@NielsvanReijmersdal-请冷静。 Yu Zhang，您错过了“激励或说服开发人员的唯一方法”声明中的一个关键条款–管理压力是激励那些尚未学习编写良好的单元测试的好处的开发人员的唯一方法。 Niels与确实知道编写良好的单元测试的好处的开发人员一起工作，因此，他当然会发现笼统的声明令人反感。
–凯特·保罗（Kate Paulk）
17年6月30日在19:25
我们都是@ YuZhang，KatePaulk和Niels的好朋友：)我认为，如果这句话是“激励或说服开发人员的一种好方法，那就是专注于测试的管理结构，并为表现最好的人提供奖励”，这可能会更好大家:)
–迈克尔·杜兰特（Michael Durrant）
17年7月1日在9:41
评论
这个问题可能是更好的套件，并且已经在softwareengineering.stackexchange.com上提出。也许您可以将问题更改为“ TESTERS如何激励”，使其更适合此SE。@NielsvanReijmersdal好点，调整了标题，谢谢！
我想很多情况下缺少单元测试的原因不是由于开发人员缺乏动力，而是由于不切实际的期限和管理层更加注重发布功能而不是代码库的质量。任何曾经重构了具有良好单元测试覆盖率的代码库的开发人员都应该已经知道单元测试的价值，并且如果他们希望继续在代码库上工作，这会激励他们编写单元测试。
@kasperd好点，我认为至少部分适用于我们的情况-这可能是我们目前人手不足。尽管至少在某种程度上存在动机问题。谢谢。
@kasperd +1，因为它的确经常是管理和/或文化问题。在我们公司中，测试是国防部不可或缺的一部分，每个冲刺都有一个用于自动化测试的时间表。这确实有助于在功能和测试之间保持健康的平衡。