测试驱动型开发不仅仅是QA

这个概念是,您从一个测试开始,它描述了正在开发的任何软件特性的一个功能。 第一次运行该测试会导致失败，因为测试的代码尚未写入。 当然，下一步是实施该功能，目标是使原始测试通过。 生命周期的第三步,也是最重要的一步,是重新构化代码。

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

为什么要使用TDD？

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

关闭反馈循环意味着缩短做出改变和学习某些东西所需的时间。 这样做的速度越快，您的灵活性就越高。 试图量化开发生产率的大多数指标都与一段时间内的工作单位有关，通过缩短接收可行反馈所需的时间，TDD可以更有效地利用这一宝贵资源。 有人说,时间就是金钱,所以这里的经济效益是不言自明的。 如果您曾经听说过有人在软件开发生命周期中提到”左移”，这正是他们所指的。

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

这两点的协同效应是显而易见的：借助代码库，开发人员能够不断地根据业务需求调整代码库，以及业务部门能够快速征求客户的反馈意见，最终形成了一个系统，使团队能够从较少的工作中获得更多价值。

充分利用TDD

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

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

文化重构

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

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

与文档不同的是,重构似乎是在期限或预算紧缩时首当其冲的事情之一,因为毕竟,有人必须编写所有这些测试。 因此，在紧急情况下，测试和文档以及其他任何不被认为是关键任务的内容都会被抛弃。 随之而来的是，代码库的总体质量和技术债务的积累不断下降。

重构是努力将代码转换为更简洁，更易于维护的代码库的过程中的一步。 它是让开发人员退后一步,识别整个系统内的模式,并做出更明智的决定,如何调整这些模式,使其更具通用性,或识别新出现的反模式,并采取措施缓解这些模式。 这甚至可能是识别何时需要将整体架构拆分为离散微服务或任何其他潜在改进之间的区别。 如果没有这一步,您可能会错过反省和渐进改进的机会,最终您的代码库可能会逐渐(或不)转变为一个大泥球。