你如何说服别人写单元测试?[关闭]

我想,这个问题不止一个方面。我发现,实际上说服开发人员开始使用测试并不难,因为使用测试的优点清单往往不言自明。话虽如此,这实际上是一个很大的障碍,我发现学习曲线往往有点陡峭,尤其是对于新手程序员来说。抛出测试框架,TDD测试优先的心态,并嘲笑那些对C#都不熟悉的人。网络或一般的编程可能太难处理了。

我是一名顾问,因此我经常需要解决在组织中实施TDD的问题。幸运的是,当公司雇用我时,通常是因为我在某些领域的专业知识,因此在吸引人们的注意力方面,我可能会有一点优势。或者,也许这只是因为作为一个局外人,我更容易进入一个新团队并说“嗨!我在其他项目上尝试过TDD,我 知道 它奏效了!“或者也许是我的说服力/固执?:)不管怎样,我经常觉得说服开发人员开始编写测试并不难。不过,我觉得难的是教他们如何编写好的单元测试。正如你在问题中指出的那样,要坚持正义的道路。

但我发现了一种我认为在教授单元测试时效果很好的方法。I have 的常用口语形式 blogged about it here ,但本质是坐下来做一些结对编程。在进行结对编程时,我首先编写了单元测试。通过这种方式,我向他们展示了测试框架是如何工作的,我是如何构建测试的,并且经常使用模拟。单元测试应该很简单,所以总的来说,即使对于初级开发人员来说,测试也应该很容易理解。最难解释的部分通常是嘲讽,但使用易于阅读的嘲讽框架,如 Moq 帮助很大。然后,当编写测试时(没有编译或通过),我将键盘交给我的程序员同事,以便他可以实现该功能。我只是告诉她/他;“让它变绿!然后我们继续下一个测试;我写测试,我旁边的‘即将被测试感染的开发人员’写功能。

现在,重要的是要明白,在这一点上,你所教的开发人员可能还不相信这是正确的编码方式。大多数开发人员似乎看到(绿灯)的一点是,当测试因一些他们从未想过会破坏任何功能的代码更改而失败时。当涵盖该功能的测试失败时,你的团队中就有了一个忠诚的TDD。或者,这至少是我的经验,但一如既往;您的里程数会有所不同:)

质量不言自明。如果你比其他人都成功,这就是你需要说的。

使用测试覆盖率工具。让它非常明显。这样,每个人都可以很容易地看到每个区域中有多少代码被通过、失败和未经测试。

然后,你可以开始一种文化,在这种文化中,“未经测试”是糟糕编码的标志,“失败”是正在进行的工作的标志,而“通过”是已完成代码的标志。

如果你也做“先测试”,这效果最好。然后“未经测试”变成“你忘了第一步”。

当然,你不需要100%的测试覆盖率。但是,在一个区域的覆盖率为1%,另一个区域为30%的情况下,你有一个指标来衡量哪个区域最有可能在生产中失败。

以身作则 如果你能得到证据表明,在单元测试代码上的回归比其他地方少。

获得QA和管理层的认可,以便您的流程强制要求进行单元测试。

准备好提供帮助 其他开始单元测试的方法:提供帮助,提供一个框架以便他们可以轻松开始,运行一个介绍性演示文稿。

你只需要习惯“如果不测试,工作就没有完成!”

编辑: 为了给我上面的滑稽评论增添更多的内容,如果一个人没有测试他们的工作,他怎么知道他们是否真的完成了呢?

请注意,如果开发代码测试的估计时间不允许,你将不得不说服其他人。

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

人酪氨酸羟化酶

干杯,

抢

称赞一个人写了更多的测试并取得了良好的成绩,向其他人展示最好的一个,并要求他们取得与此相同或更好的成绩。

没有一个或多个痛点,人(和过程)就不会改变。因此,您需要找出重要的痛点,并演示单元测试如何帮助解决这些痛点。

如果你找不到任何明显的痛点,那么单元测试可能不会给你当前的流程增加很多价值。

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

有两种方法:让项目经理相信单元测试可以提高质量并总体上节省时间,然后让他强制进行单元测试。

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

另一种可以证明单元测试是必不可少的情况是,当一个版本实际交付时,由于最后一刻的更改,它包含了一个严重的错误。

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

例如,在编写和审查单元测试之前,任何东西都不能签入。

也许reefnet_alex的回答对你有帮助: Is Unit Testing worth the effort?

我想是福勒说的: “不完美的测试,经常运行,是 比完美的测试要好得多 从来没有写过” 把这理解为给了我 允许我编写测试 认为它们即使在以下情况下也会非常有用 我的其余代码覆盖率是 可悲的是不完整。

你提到你的经理同意进行单元测试。如果是这样的话,那他(她)为什么不执行呢?你的工作不是让其他人跟随或教他们,事实上,如果你试图把它强加给其他开发人员,他们通常会怨恨你。为了让其他开发人员编写单元测试,经理必须强调这一点 强烈地 。最终,重点的一部分可能是单元测试实施的教育,你最终可能会成为教育者,这很好,但管理就是一切。

如果你在一个由团队决定实现风格的环境中,那么你在团队动态应该如何发展方面有更多的发言权。如果你在这种环境中,团队不想在你强调单元测试的同时强调单元测试,那么也许你找错了团队/公司。

我发现“传福音”或说教很少奏效。正如其他人所说,按照自己的方式为自己的代码做事,让别人知道你这样做了,但不要试图强迫别人这样做。如果人们问起这件事,请给予支持和帮助。主动提出做一些午餐时间的研讨会或非正式的狗和小马表演。这将远远不止是向你的经理或其他开发人员抱怨你很难为他们编写的代码编写测试。

缓慢而稳定——它不会在一夜之间改变。

有一次,我意识到在我工作的一个地方,同行评审的接受度大大提高了。我的团队只是做了,不再试图让别人做。最终,人们开始问我们是如何取得一些成功的。那就容易多了。

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

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