java - 如何采用 TDD 并确保遵守？

Question

我是一名高级工程师，在一个由其他四人组成的团队中工作驱动大型美国职业体育网站的内容管理应用程序地点。我们两年前就开始了这个项目，并选择了Java 作为我们的平台，虽然我的问题不是 Java 特定的。自从我们开始了，我们的队伍出现了一些流失。我们每个人都有在决定实现方面有很大的自由度细节，尽管重要的决定是通过共识做出的。

我们的项目是一个相对年轻的项目，但我们已经到了一定程度当没有一个开发人员知道有关该应用程序的所有信息时。首要的原因是我们的发展速度很快，其中大部分发生在我们运动的赛季揭幕战前的紧缩中；和事实上，我们的测试覆盖率基本上是 0。

我们都了解 TDD 的理论优势并同意该方法将改善我们的生活和代码的原则如果我们一开始并坚持通过年。这从未发生过，现在我们负责一个未经测试的仍然需要大量扩展并被积极使用的代码库在生产中并受到公司结构的依赖。

面对这种情况，我只看到两种可能的解决方案:(1)为现有代码追溯编写测试，或 (2) 尽可能多地重写该应用程序的实用性，同时狂热地坚持 TDD原则。我认为(1)大体上是不切实际的，因为我们在项目中有一个 hell 般的依赖关系图。我们几乎没有组件可以单独测试；我们不知道所有的用途案例；并且在测试推送期间用例可能会发生变化由于业务需求或对不可预见问题的 react 。为了这些原因，我们不能确定我们的测试结果是否一旦我们完成了高质量。带领团队有风险进入一种虚假的安全感，因此微妙的错误会悄悄潜入没有人注意到。鉴于前景黯淡投资返回率，我自己或我们的团队领导很难证明这一点努力管理。

方法(2)更有吸引力，因为我们将遵循测试优先原则，从而生成几乎 100% 覆盖的代码 bat 。即使最初的努力导致覆盖代码的孤岛首先，这将为我们提供一个重要的滩头阵地项目范围的覆盖并帮助解耦和隔离各种组件。

这两种情况的缺点是我们团队的业务生产力可能会显着放缓或蒸发完全在任何测试插入期间。我们不能在此期间这样做业务驱动的紧缩，尽管紧随其后的是相对平静我们可以利用它来达到我们的目的。

除了选择正确的方法((1)、(2)或另一个未知的解决方案)，我需要帮助回答以下问题:我的团队如何确保我们的努力不从长远来看，由于未维护的测试和/或无法编写而浪费随着业务需求的增加而出现新的？我对广泛的事物持开放态度这里的建议，无论是胡萝卜还是大棒。

无论如何，感谢您阅读这个自找的困境。

Answer 1

“这两种情况的不利之处在于，我们团队的业务生产力可能会在任何测试推进期间显着放缓或完全消失。”

这是对事实的常见误解。现在你有你不喜欢并且难以维护的代码。 “ hell 依赖图”等。

因此，您一直在进行的“紧缩”开发导致了昂贵的返工。返工如此昂贵，你不敢尝试。这说明您的紧缩开发不是非常有效。当时它看起来很便宜，但回想起来，你注意到你真的在浪费开发资金，因为你创建了有问题的、昂贵的软件，而不是创建好的软件。

TDD 可以改变这一点，这样您就不会生产维护成本高的紧缩软件。它不能解决所有问题，但可以清楚地表明，将注意力从“紧缩”转移可以产生更好的软件，从长远来看成本更低。

根据您的描述，您当前的部分(或全部)代码库是负债，而不是 Assets 。现在想想 TDD(或任何学科)将如何降低该责任的成本。当您产生负债时，“生产力”的问题不适用。

TDD 的黄金法则:如果您停止编写有责任的代码，组织就会获得积极的投资返回率。

小心询问如何保持当前的工作效率。其中一些“生产力”正在产生没有值(value)的成本。

“我们几乎没有一个组件可以单独测试；我们不了解所有用例”

正确。对现有代码库进行改造单元测试真的很难。

“有可能导致团队陷入错误的安全感，从而导致细微的错误会在没有人注意到的情况下悄悄潜入”

错误。没有“虚假的安全感”。每个人都知道测试充其量是艰难的。

此外，现在你有可怕的错误。你的问题太糟糕了，你甚至不知道它们是什么，因为你没有测试覆盖率。

与无法测试的代码相比，处理几个细微的错误仍然是一个巨大的改进。我会在任何一天对未知的错误进行细微的错误处理。

“方法(2)更有吸引力”

是的。但是。

您之前的测试工作被一种奖励紧缩编程的文化所颠覆。

有什么改变吗？我对此表示怀疑。你的文化仍然奖励紧缩编程。您的测试计划仍有可能遭到破坏。

您应该考虑一个中间立场。不能指望你在一夜之间“狂热地坚持 TDD 原则”。这需要时间和重大的文化变革。

您需要做的就是将您的应用程序分解成多个部分。

例如，考虑 模型 - 服务 - View 层。

您拥有需要广泛、严格的可信测试的核心应用程序模型(持久化事物、核心类等)。

您的应用程序服务需要进行一些测试，但受制于“在测试推送期间，由于业务需求或对不可预见问题的 react ，用例可能会发生变化”。尽可能多地进行测试，但不要违反为下一季按时发货的要求。

您有需要一些测试但不是核心处理的 View /演示内容。这只是介绍。随着人们想要不同的选项、 View 、报告、分析、RIA、GUI、浮华和嘶嘶声，它会不断变化。