Home Blogs 测试驱动型开发不仅仅是QA
Applications

About The Author

Outline

在软件世界中,许多人(如果不是大多数人)都开始将(TDD)狭隘地认为 是软件开发所特有的一个过程。 许多讨论和辩论都围绕着使用特定工具或技术进行,这些工具或技术旨在根据预定义的要求列表来执行代码的每一个角落,目的是证明给定的代码库按描述的方式运行。 正如经常发生的那样,很难将信号与噪声分离,将原理与实践分离,因此我们在实施细节中迷失了方向,忽视了最初的意图。 因此,让我们退一步,重新思考围绕测试驱动型发展的对话:具体而言,它是什么,它如何帮助您的企业?

什么是TDD?

在企业环境中,软件的目的是为该企业增加价值。 因此,任何开发工作的关键挑战之一是将业务要求和目标映射到相应的系统要求。 接下来的问题是:如何编写软件来满足这些要求;随着项目及其代码库的增长,如何确保您的软件 继续 满足这些要求

进入测试驱动型开发。

测试驱动开发(TDD)是一种通过编写描述和练习软件的测试来编写软件的组织方法。 在其核心,TDD是三个步骤的重复:编写失败的测试,使其通过,重构。

这个概念是从一个测试开始,该测试描述了正在开发的任何软件功能的一个功能。 第一次运行该测试应该会导致失败,因为正在测试的代码尚未编写。 当然,下一步是实施该功能,目的是让原测试通过。 生命周期中的第三个也可以说是最重要的步骤,就是对代码进行重构。

编写软件具有挑战性,不仅是因为它的内在品质,也是因为它的动态性质。 业务需求可能会不断变化,因此,软件需求需要能够适应。 今天编写的代码将满足当今的需求,但明天,或一个月后,某些内容将会发生变化,因此,今天的代码可能不再是解决特定问题的最佳方式。 通过引入用于比较软件内容的机制 记录软件内容 应该 我们现在有了一个强大的工具,它可以让我们无畏地拆分,重写代码,并重新布线,以最好地满足当今的要求,因为我们可以确信,只要我们所有的测试都通过,系统的输出应该是相同的。

我们为什么要使用TDD?

赫尔辛基大学2014年进行的一项审查 发现,在许多情况下,TDD在缺陷,质量,复杂性和可维护性方面产生了积极影响,但这些改进可能会以增加开发工作为代价。 这并不是一个令人惊讶的结论,因为编写额外的测试将需要额外的努力-但这种性质的研究似乎遗漏的是TDD的主要好处,即 反馈

结束反馈循环意味着缩短进行更改和学习所需的时间。 这样做的速度越快,就越 敏捷 。 大多数尝试量化开发生产率的指标都与一段时间内的工作单位有关,通过缩短接收可操作反馈所需的时间,TDD可以更有效地利用这种宝贵的资源。 有人说时间就是金钱,所以这里的经济效益是不言而喻的。 如果您曾经听说过有人在软件开发生命周期的上下文中提到”左移”,这正是他们所指的。

为您的应用程序配备测试套件的另一个好处是您可以实现自动化。 开发人员不仅可以将这些测试作为开发生命周期的一部分运行,还可以将它们作为烟雾测试或CI/CD管道的一部分由其他系统运行 。 通过自动化将代码交付到市场的步骤,它可以更快速地整体交付产品,从而加快您可以从用户处收到的反馈,这些反馈随后可以被解释并应用到下一个迭代中。

这两点的协同效应是显而易见的: 借助代码库,开发人员能够不断地根据业务需求调整代码库,并且企业能够快速征求客户的反馈,因此形成了一个系统,使团队能够从更少的工作中获得更多价值。

充分利用TDD

测试驱动型开发只是测试软件的许多不同方法之一。 无论您选择如何实施它,重要的部分是它为您的组织带来价值。 与任何其他学科一样,您应该完全根据您的组织的需求自由使用,根据您认为合适的情况进行调整或完全不使用它。 话虽如此,如果你选择走TDD路,正如先知克拉普顿所预言的那样:“这就是你使用它的方式。”

与任何其他工具一样,TDD的有效性和价值取决于其实施情况。 在软件开发中,各种工具或技术往往被变成替罪羊,以解释项目的失败或缺点,但它是一个可怜的工匠指责他的工具。 因此,让我们关注如何充分利用TDD。

文化重构

TDD的最后一个也是最重要的步骤是重构代码,但要使TDD正常工作,可能不是唯一需要进行重构的步骤 。 如果您选择实施某种形式的”测试驱动型发展”,那么周围的文化也必须适应以支持这种类型的发展理念,这一点非常重要。

在TDD的情况下,最常见的故障往往是连续的写入测试周期,使其通过,然后重构从未实际完成,而是通过跳过重构步骤而短路。 问题往往不是TDD或任何其他特定技术,而是软件开发的文化。

与文档不同的是,重构似乎是在截止日期或预算紧张时最先抛出的事情之一,因为毕竟, 有人 必须编写所有这些测试。 因此,在关键时刻,测试和文档以及其他任何不被视为关键任务的内容都将被丢弃。 随之而来的必然是代码库总体质量的稳步下降,而其位置则是技术债务的积累。

重构是该过程中的一个步骤,它努力将简单工作的代码转换为更干净,更易于维护的代码库。 这部分允许开发者退一步,识别整个系统中的模式,并做出更明智的决定,如何调整它们,以更通用,或识别新出现的反模式,并采取措施来缓解它们。 它甚至可能是在何时需要将整个体系结构拆分为独立的微服务或任何其他潜在改进之间的区别。 如果没有这一步,你可能会错过反省和逐步改进的机会,最终你的代码库的风险是一个渐进的(或不)转变成 一个大的泥球。

要获得测试驱动型开发的优势,文化必须从整体上看待流程及其潜力,并投入时间应用完整的”红,绿,重构”周期,而不仅仅是权宜之计。

闪亮的新玩具

当涉及到系统设计作为一个整体时,通常会花费太多的时间来规划系统的细节,而不实际编写任何代码。 一个”绿色领域”项目可能令人兴奋,它具有与一张干净的纸相关的所有预期潜力。 工程师和建筑师都是这种尝试的受害者,他们主张使用一种”每月风味”技术,忽视任何警告信号,它可能不适合这个特定的项目,有利于有机会尝试新的或酷的东西。 几个月后,framework-du-jour不再满足团队的需求,代码的质量也在下降,我们又回到了技术成为项目糟糕结果的替罪羊的部分。

最后,重要的是用于促进TDD的技术,方法或框架适用于团队和业务。 如果你被你的工具束缚,不仅是他们没有 增加 价值,但他们积极反对你. 仔细评估您打算使用的任何框架,并花时间确切了解您将如何使用它。 这种方法适用于所有设计决策,而不仅仅是与TDD相关的设计决策!

总结

简而言之,像TDD这样的东西的想法是提供一个框架,以更快捷的方式收集反馈,而不是简单的一种防止错误出现在您的代码库中的技术。 无论您选择哪种方法,关键在于它能使您的企业及其软件更快地适应不断变化的趋势和业务需求。 在此过程中,请注意,TDD及其对应产品不仅仅是您可以要求您的开发团队实施后忘记的事情, 为了有效地利用这些技术,必须在深入研究框架和工具等实施细节之前,在文化层面谨慎地采纳和启用该方法。

Tags

Just For You