如何应对那些破坏人们的TDD？

Question

就我个人而言，我更喜欢单元测试并将其编写为“良好”的覆盖范围。 （假设我尽可能努力地编写好的测试;）

通常一段时间后，有些人需要在代码中添加一些功能（向类中添加方法等）。他没有打破那些书面单元测试，但拒绝写额外的（这将涵盖他编写的代码的其他功能）。 这导致了tdd过程中的一个大漏洞（更糟糕的是可能是一个破窗口效应）

我能做些什么让他写下这些测试？ 你是如何与这些人打交道的？

Answer 1

请记住，TDD主要不是为了产生良好的单元测试覆盖率;它首先是关于激励良好的设计，关于确保您编写的代码符合您的预期，以及提供高质量的测试第三。

当另一个程序员在没有编写测试的情况下扩展课程时，他们错过了这些好处，你应该对他们表示同情。但是当你工作的时候，你将继续以最好的方式工作（首先测试），因为你知道你得到的解耦代码对于消费者来说很容易，而且你的代码符合你的期望。

对您来说最大的痛苦是您必须小心重构的内容：如果您正在重构正在测试的代码，您可以快速进行，并且设计将快速安全地改进。如果您要重构未经过测试的代码，则应该非常谨慎地重构它（可能只使用可靠的自动化工具）或添加测试。

最后，您将继续受益于您对TDD的使用，因为您可以更快地生成更清晰，更正确的代码，同时您的TDD受损同事将受到影响。

Answer 2

不要将此视为对抗！你问的是如何强迫同事做某事他/她显然没有任何好处。你无法让某人使用TDD - 正如你自己已经看到的那样。开发人员接受TDD的唯一方法就是当其他人帮助他们达到“啊哈！”时。时刻。作为一个同事尊重他人并通过你的行动向他/她展示，并积极地想要帮助他/她克服心理上的困境。

Answer 3

结对编程。有两个人在做某事，程序员不太可能采取这样的捷径。

Answer 4

如果您有构建过程，则可以使用NCover或PartCover之类的工具，如果覆盖范围不够，则无法构建。

Answer 5

除了公司政策和经理的影响之外，你无能为力。也许在您的源代码管理工具中有一些方法要求公开的任何单元测试都被标记为。

你甚至可以编写一个宏，它是你的构建过程的一部分，它寻找标记为PUBLIC的任何东西（我是一个VB人），然后检查以确保在解决方案的某个地方有一个带有代码注释的单元测试足以链接它。没有相关的单元测试会破坏构建并向整个开发组发送一封电子邮件，这足以使所述非测试人员感到羞耻。

也许我会把它设置在这里，现在我想起来了......

Answer 6

使用某些工具跟踪代码覆盖率，例如对于Java，有Emma，并为每个版本生成管理报告。当数字过低或下降时，管理层应调查原因。

Answer 7

以身作则。您的同事可能根本不了解如何正确使用TDD。下次发生时，为它们编写单元测试。请务必指出这一点：“嘿，我注意到你没有进行单元测试就把 x 功能添加到程序中，所以我为你写了一个并把它放在这里。”这样他们就有了一个例子，不会因为不得不问单元测试而感到尴尬。

只做一次或两次。之后，请务必提及以后的任何事件。你会对礼貌的差异感到惊讶“嘿，你没有为功能 y 编写一个单元测试，如果你为我写一个，那真的会帮助我” 。请记住，您的目标不是尝试制作他们编写测试。这使得编写测试比不编写测试更麻烦。

如果上述方法不起作用，是时候与管理层讨论了。你已经试图友好地解决这个问题了，所以现在是时候考虑一​​种不那么友好的方法。

Answer 8

教你的同事如何做TDD，这样他们就可以颠倒大脑（我第一次尝试TDD时有这种感觉）并开始先写测试。

我曾与我的程序员朋友做过实验，他不知道TDD。我来到他家，我们开始使用TDD编写俄罗斯方块（我们那天花了大约6个小时并且进展顺利）。首先我写了一个测试方法，然后他编写了代码来通过测试。在开始时，他略微反对写“可能有效的最简单的东西”（例如在第一次琐碎的测试中硬编码返回值）并且没有提前计划，但无论如何他把它吸了起来并遵循我的指示。随着我们的进步，似乎慢慢地他开始明白这一切的重点。

Answer 9

播放“不要欺骗我兄弟！”的视频作为警告的家伙