如何处理那些破坏TDD的人？

Question

如何处理那些破坏TDD的人？

5

个人而言，我非常喜欢单元测试，并为它们编写“良好”的覆盖率（假设我尽可能努力地编写良好的测试；）

通常情况下，一段时间后，其他人需要向代码中添加一些功能（例如向类添加方法等）。他不会破坏已编写的单元测试，但拒绝编写额外的测试（这些测试将涵盖他编写的代码的其他功能）。这导致了TDD过程中的一个巨大漏洞（甚至更糟糕的是，可能会出现破窗效应）

有什么办法能让他编写这些测试呢？你如何处理这些人？

- Calamitous

主观和争议性的（“让他”和“处理”）。 - ChrisW

这个问题与首先让同事编写测试有何不同？我非常确定这方面已经在这里进行了深入的讨论。 - EBGreen

在Jason Punyon的回答基础上进行扩展：如果你不是在测试代码覆盖率，而只是试图为了“良好的”覆盖率编写测试套件，那么你的测试套件是不充分的。 - William Pursell

9个回答

7

不要把这视为对抗！你正在询问如何强迫一位同事去做他/她明显没有看到任何好处的事情。你不能让某个人使用TDD - 正如你自己已经看到的那样。开发人员只有在有人帮助他们达到“啊哈！”时，才会接受TDD。作为同事之间相互尊重，并通过你的行动向他/她展示积极的想法，帮助他/她克服心理障碍。

- Rex M

5

配对编程。两个人一起工作，程序员很少会采取这样的捷径。

- Jay Bazuzi

1

+1. 代码审查具有相同的效果。 - Kena

4

如果您有构建过程，可以使用NCover或PartCover等工具，如果覆盖率不足，则构建将失败。

- JPunyon

添加覆盖率测试是唯一明智的做法。有谁能声称拥有一个完整的测试套件，却不测试代码覆盖率呢？ - William Pursell

2

除了公司政策和经理的后果，你对此无能为力。也许你的源代码管理工具有一些方式可以要求任何公共事务都必须有一个标记为这样的单元测试。

你甚至可以编写一个宏，将其作为构建过程的一部分，查找任何标记为PUBLIC（我是VB小伙子），然后检查是否在解决方案中有足够链接的代码注释的单元测试。没有关联的单元测试会破坏构建并向整个开发组发送电子邮件，以充分地羞辱该非测试人员。

也许我现在要设置它...

- rwmnau

你不能通过羞辱来让人们去使用TDD。这已经被尝试过并且失败了。唯一的方法是帮助他们克服心理障碍，达到自己的“顿悟”时刻，从而让他们自己采用TDD。 - Rex M

我并不是说要让他们感到羞耻，以至于不好意思来上班——显然这会让你的办公室成为一个糟糕的工作场所。你应该创造一种文化，在这种文化中，可以轻松地对某人打破构建进行调侃，每个人都可以从中获得乐趣。 - SqlRyan

1

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

- starblue

1

以身作则。你的同事可能不知道如何适当地使用TDD。下一次发生这种情况时，为他们编写一个单元测试。确保向他们指出：“嘿，我注意到你在程序中添加了x功能，但没有编写单元测试，所以我为你编写了一个并放在这里。”这样他们就有了一个例子，不会因为需要问如何进行单元测试而感到尴尬。

只做一两次就好了。之后，一定要提及任何未来的情况。你会惊讶于礼貌的“嘿，你没有为函数y编写单元测试，如果你能为我编写一个，那真的会帮助我很多”的话语所产生的巨大影响。记住，你的目标不是试图让他们编写测试。而是让编写测试比不编写测试更容易。

如果以上方法不起作用，那么就该与管理层进行讨论了。你已经试图友好解决这个问题了，所以现在考虑采取不太友好的方法。

- Jason Baker

0

教你的同事如何进行TDD，这样他们就可以颠覆自己的思维方式（我第一次尝试TDD时也有这种感觉），并开始先编写测试。

曾经我和一个不了解TDD的程序员朋友做过一个实验。我去到他家，我们开始使用TDD编写俄罗斯方块游戏（那天我们花了大约6个小时，进展顺利）。首先我编写了一个测试方法，然后他编写了代码来通过测试。一开始，他稍微反对编写“可能起作用的最简单的东西”（例如在最初的琐碎测试中硬编码返回值）而不是提前计划很多，但无论如何他都接受了我的指导。随着我们的进展，他似乎慢慢地开始理解这一切的意义所在。

- Esko Luontola

-1

播放“不要对我使用电击枪！”的视频作为警告

- OTisler

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Jay Bazuzi · Accepted Answer

记住，TDD（测试驱动开发）首先不是为了生成良好的单元测试覆盖率；它主要是关于激发 良好的设计，其次是确保你编写的代码符合预期，第三是提供高质量测试的集合。

当另一个程序员扩展类时，如果没有编写测试，他们会错过这些好处，你应该对他们感到遗憾。但当你工作时，你会继续按照你所知道的最佳方式（先测试）进行工作，因为你知道这样可以获得易于使用者使用的松耦合代码，并且你的代码符合预期。

对你来说最大的痛苦在于你必须谨慎重构：如果你正在重构已经有测试的代码，你可以快速进行，并且设计会快速而安全地改进。如果你正在重构未经测试的代码，则应该非常谨慎地进行重构（也许只使用可靠的自动化工具来完成），或者添加测试。

最终，你将继续从使用TDD中受益，因为你可以更快地生成更清晰、正确的代码，而那些不使用TDD的同事则会受苦。