使球在TDD上滚动

我是一个开发团队的成员，该团队与许多其他团队一起维护和改进已使用了至少15年的应用程序。最初构建和设计TDD时闻所未闻。

该应用程序相当稳定，我们很少遇到显示错误，但是我们每周平均会发现大约一两个错误，这严重降低了服务质量。这些错误要花很长时间才能找到并修复，这在很大程度上是因为手指指向的，而我们仅有的测试是接口测试。因为在修复该错误之前浪费了很多时间，所以我和另一个开发人员计划提出测试驱动开发。即将进行新的大修，我们希望在新模块上完成几乎完整的单元测试，我们还计划建议为我们必须更改的任何遗留代码（例如，错误修复或功能实现）构建测试单元。 ），但不要花时间为尚未引起问题的代码开发测试用例。

对我来说，这似乎是合理的。本月，我们修复了一个错误，该错误花费了两周的时间，但是如果完成了单元测试，则可以在部署之前发现该错误。但是对于我们的经理们来说，他们好像要花更多的钱。

我如何说服我们的客户他们想花钱进行单元测试和测试驱动的开发？是否有任何研究表明单元测试的投资回报率？

直接将成熟的TDD合并到旧代码中，维护项目非常困难。我见过的一种非常有效的方法是这种方法。对于每个出现的错误，创建一个自动的非单元测试来演示该错误。所谓“非单元”，是指可以触及系统许多部分，影响数据库和文件系统等的事物；但所谓“自动化”，是指无需人工干预即可运行。无论如何，这是您需要在回归套件中进行的测试。编写它可以完成很多事情：即使使它处于非常粗糙的水平，它也使您可以测试代码，并且使您接触可能与该错误有关的代码群，因此它可以教育并告知您有关错误的信息。非常具体的相关材料。

但这还没有结束。一旦该测试运行并且运行为红色（说明代码中的错误），请花点时间找出问题所在（无论如何都必须这样做）。但是暂时不要修复。找出问题所在后，请写一个单元测试证明这个问题。现在，您可以使用一些东西了（而且，顺便说一句，您可能不得不将更多内容重构为更高的可测试性）。修复错误。观看单元测试合格。也许用一些极端情况充实它；得到一个单元-只需花费您两周的时间-牢固，干净且经过测试。现在运行回归测试并观察它是否通过（当然，如果没有通过，您还需要做更多的研究和单元级的工作-迭代直到它也通过为止）。全部检查一下。您得到了什么？对先前失败的代码进行回归测试。对先前失败的代码进行单元测试。失败的工作代码。设计更好的代码，因为现在它比以前更具可测试性。对您的代码库更有信心，

它不是“纯” TDD。但是，随着时间的推移，它可以快速显示结果并提高代码质量。结果将帮助您获得管理层的支持。

在我的公司，我只是采用JoelOnSoftware的“只有咕gr作法”的方法，并在通常只需要将一些废弃的控制台应用程序一起黑客入侵时就开始编写单元测试。我开始通过更稳定的发行版来更快地完成工作，并因此而受到关注。当被问到我在做什么时，我解释说，每当我修改旧代码或编写任何新代码时，我就开始使用TDD并编写单元测试。我的同伴开发人员开始感到好奇，并开始自己使用集成的单元测试。我认为目前尚无关于为可用的旧代码编写测试的良好论据，但是如果您可以证明编写自动化测试比编写控制台黑客面条更快更方便，那么聪明的开发人员将紧随其后。带来更高质量软件的其他好处也将存在，但使开发人员登录的关键在于表明它使他们的生活更轻松。就业务签约而言，它可以带来更好的软件，并且可能比以前花费更少的时间发货这一事实，应该足以说服他们。

首先，您的态度和对质量价值的真诚感会增加客户的金钱。这是我对如何说服经理和客户的想法：

• 收集您最近6个月内要修复的错误的指标，以及修复该错误所花费的最短，平均和最长时间。
• 对于您已修复或具有相关上下文的所有错误，请尝试编写涵盖这些区域的单元测试。
• 对于您正在处理的错误以及将要处理的错误，甚至在进行任何更改之前，请尝试围绕这些区域编写单元测试。然后编写代码找出原因并解决。查看它是否破坏了您现有的任何测试用例。如果是，请解释并帮助您的同龄人理解单元测试的重要性。
• 一旦所有开发人员都了解了单元测试的重要性，请他们继续做这么多天/周的工作。
• 随着时间的流逝，团队的生产率应提高到一定程度，以使您的经理和客户都对生产率和代码质量的提高速度感到惊讶。它有点耗时，但是值得尝试。

还有另一种方法，那就是尝试与您的经理一起参加周围发生的敏捷会议。当然值得参加。

如果您认为没有任何效果，请继续...加入适合您的地方。坦率地说，这就是我所做的。当一切都失败了，我继续前进;）

并且知道编写代码后单元测试不是真正的TDD，但这始终可以是第一步。它至少非常适合这里。

祝你好运，成功！