您如何说服其他人编写单元测试?[闭门]

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

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

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

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

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

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

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

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

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

请注意,如果开发代码的测试评估中不允许有时间,那么您将有一场说服他人的战斗。

编码工作和测试工作之间的一对一分割似乎是一个不错的数字。

嗯

干杯

抢劫

如果一个人写了更多的测试,并产生了好的结果,那么就赞美他,向其他人展示最好的测试,并要求他们产生与此相同或更好的结果。

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

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

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

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

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

单元测试可以显示为不可或缺的另一种情况是,当一个发行版实际交付时,由于最后一分钟的更改而包含了一个严重的bug。

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

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

我想是福勒说的: “经常运行的不完善测试是 比完美的测试要好得多 把这个解释为给我 我的代码覆盖的其余部分是 不幸的是,它不完整。

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

如果您所处的环境是由团队决定实现的风格,那么您就有更多的发言权来决定团队的动态应该如何。如果您处于这种环境中,而团队不想在您强调单元测试的同时强调单元测试,那么您可能在错误的团队/公司。

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

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

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

这导致引入的bug很快被修复。