tdd 使用详解_对我有用的TDD

tdd 使用详解

肯特·贝克 （ Kent Beck ） 重新发现了测试驱动的开发 （又名TDD），并于2002年在他的著名著作中对其进行了解释。2014年，David Heinemeier Hansson（Ruby on Rails的创建者）表示TDD 已死 ，只会损害体系结构 。 Robert Martin （ SOLID原理的发明者） 不同意并解释说TDD可能仅在某些情况下不起作用。

几天后，他甚至将 TDD的重要性与洗手对医学的重要性进行了比较，并补充说：“如果有一天，TDD在其背后有法律效力，这不会令我感到惊讶。” 两年后，也就是几个月前，他写了更多有关它的文章， 越来越 多 。 这个话题似乎很热。 当然，我有自己的看法。 让我分享。

Paolo Sorrentino的《 La Grande bellezza（2013）》

从理论上讲，TDD的意思是“首先编写测试，然后编写代码”。 在实践中，根据我过去四年与250多个开发人员合作的经验 ，这意味着在我们心情愉快且无事可做时编写测试。 如果我们从字面上理解TDD，这只是合乎逻辑的 。

我从没做过TDD：首先进行测试，然后进行编码。

在没有班级的情况下为班级编写测试很难 。 如果我们谈论的是真实代码，而不是计算器示例，我什至说不可能。 这也是非常低效的 ，因为按定义定义的测试比其验证的代码要严格得多，因此首先创建它们将导致许多重做周期，直到设计稳定为止。

在过去的四年中，我个人已经用 Java，Ruby，PHP和JavaScript 编写了将近30万行代码，而我从没有做过TDD：“编写测试，使其运行，使其正确。” 曾经

编码，部署，破坏，测试，修复

即使我非常喜欢自动化测试（单元或集成），并且完全同意 Bob叔叔：那些不编写测试的人必须入狱 ，但我对TDD有自己的解释。 看起来是这样的：

• 首先，我编写代码时没有进行任何测试。 很多代码。 我实现功能并创建设计。 数十堂课。 当然，构建是自动化的，配置了部署管道，我可以在沙箱中亲自测试产品。 我确保“ 它可以在我的机器上工作 。”
• 然后，我将其部署到生产中。 是的，它对我的​​“用户”没有任何测试，因为它对我有用。 如果是开源项目或我的一个宠物项目 ，他们要么是真实用户，要么是金钱项目，就成为手工测试人员。
• 然后，他们打破了它。 他们要么测试它，要么使用它。 没关系 他们只是发现问题并报告错误。 尽可能多。
• 在报告了一些错误之后，我立即选择了最严重的错误，然后……创建一个自动测试 。 该错误向我传达了我的测试很弱的信息。 我必须先修复它们。 一个新的测试将证明该代码已损坏。 或者，也许我修复一个现有的。 这是我“首先测试”的地方。 在设法破坏构建并通过新测试证明问题的存在之前，我不会涉及生产代码。 然后，我执行git commit.
• 最后，是时候解决问题了。 我对生产代码进行了更改，以确保构建再次变为绿色。 然后，我执行git commit和git push. 我回到“部署”步骤； 更新的产品归我的用户所有。

有时，我必须对产品进行认真的修改，例如引入新功能或执行大量重构。 在这种情况下，我将回到第一步，并且无需进行测试。

背后的推理

这种无须测试的方法背后的理由很简单：我们不需要测试就可以了，这主要是因为我们知道从技术上讲不可能测试所有内容或修复所有错误。 我们只需要解决企业可见和无法忍受的问题。 如果企业不在乎或我们的用户/测试人员看不到我们的错误，我们一定不要浪费项目资源来修复它们。

只有在用户通过报告错误表示对测试的需求时，我才会稍后创建测试。

另一方面，当企业或我们的用户/测试人员抱怨时，我们必须对自己非常严格； 我们的测试系统薄弱，必须首先修复。 我们不能只是修复生产代码并进行部署，因为在这种情况下，经过一些重构，我们可能会再次犯此错误，而我们的测试将无法捕获它。 用户将再次找到该错误，并且企业将再次向我们付款以修复该错误。 那将浪费资源。

如您所见，这都是金钱驱动的。 首先，如果没有人为之付出，则不要修复任何东西。 其次，如果他们实际付款，则一劳永逸地修复它。 就这么简单。

动态

由于采用了“仅测试并修复”的方法，因此在整个项目生命周期中，生产代码和测试代码之间的平衡并不相同。 当项目开始时，几乎没有测试。 然后，测试的数量与错误的数量一起增长。 最终，情况趋于稳定，我们可以将产品从Beta版迁移到第一版。

我创建了一个简单的命令行工具 ，以演示我的一些项目的统计数据，以证明我的观点。 看一下这些图：

yegor256 / takes （Web框架，Java）：

yegor256 / xembly （XML构建器，Java）：

jcabi / jcabi-aspects （AOP库，Java）：

yegor256 / s3auth （S3网关，Java）：

第一个商业项目：

第二个商业项目：

在每个图中有两个部分。 顶部的第一个示例演示了生产命中代码 （绿线），与测试相关的HoC（红线）以及报告给GitHub的问题数量（橙色线）的动态。

底部显示了与测试相关的HoC部分相对于所有项目活动有多大。 换句话说，它显示了项目多少精力投入到自动化测试，与总工作量比较。

这是我要您注意的：在每个项目中，曲线的形状几乎相同。 它看起来与学习曲线非常相似，在学习曲线中 ，我们开始快速学习，然后随着时间的推移而放慢速度：

这完美地说明了我上面所描述的内容。 我在项目开始时不需要测试； 稍后，当我的用户通过报告错误来表达对它们的需求时，便创建了它们。 对我来说，这种动态看起来很合逻辑。

您也可以使用我的工具分析您的项目并查看图表。 了解您将获得哪种曲线将很有趣。

您可能还会发现这些相关的帖子很有趣： 拒绝Bug修复的一些有效理由 ； 虫子受欢迎 ; 傻瓜不要写单元测试 ; 好的程序员写没有错误的代码，不是吗？ ; 您什么时候停止测试？ ;

翻译自: https://www.javacodegeeks.com/2017/03/the-tdd-that-works-for-me.html

tdd 使用详解