测试驱动开发（英文全称Test-Driven Development，简称TDD）是确保代码具有良好质量的一种方法。它要求开发人员在编写代码之前思考代码应该如何工作，然后让你严格测试，以确保代码确实按照规划的要求运行。
使用测试驱动开发的确有很多好处，但是，使用这种方法也有一些缺点。
我（作者）所在的公司遵循极端的编程实践。我们每天都会核对流程，并使用测试驱动开发来编写我们的软件。在这篇文章中，我想分享我对TDD的专业看法和经验。
什么是TDD？
首先，什么是TDD？测试驱动开发是一种使用测试来“驱动”（或引导、指导）实现的编程风格。
TDD的三个规则
虽然TDD流派不止一种，但这一切都始于Kent Beck 制定了所谓的“TDD 三大规则”
这是TDD的三个规则：
-
编写生产代码只是为了通过失败的单元测试。
-
编写的单元测试不要超过足以失败的程度（编译失败就是失败）。
-
编写的生产代码不要超过通过一个失败的单元测试所需的代码。
正如前面提到的，TDD的流派不止一种，但主要规则是先写测试。
TDD鼓励非常小的实施步骤（有时只需几分钟）和快速的反馈循环。
TDD的好处
因此，让我从最明显的好处开始，然后转向TDD不太明显的好处。
1. 高且有意义的代码覆盖率
首先，通过使用TDD，你可以获得高且有意义的代码覆盖率。
在典型的TDD循环中，除非失败的测试需要此生产代码存在，否则你不会编写生产代码，这使得生产代码和测试本身的质量更好。这当然会导致错误密度下降。
你制造的错误会更少！
你不需要突变测试或类似的东西来知道你的测试实际上是在测试某些东西 - 因为你看到它们失败了。
2. 信心
由于测试覆盖率高且有意义，人们通常对他们编写的代码充满信心。他们知道他们可以更快地发布，因为整个代码都经过了单元测试！而且，根据你使用的 TDD 流派，代码还可能有其他类型的测试，例如验收或集成级别测试。
3. 文档
创建的单元测试可以成为非常好的代码文档。例如，当新开发人员开始开发新的软件时，他们可以开始查看单元测试而不是代码本身，并且非常清楚生产代码的逻辑是什么以及它的设计目的是什么做。
4.架构反馈
有些人会说使用测试驱动开发真的很复杂，因为他们使用的框架不太适合单元测试，他们需要集成测试甚至系统级测试。这实际上是测试驱动开发的另一个好处。
测试驱动开发提供了非常好的架构和代码质量反馈，因为使用单元测试测试代码的容易程度与代码的模块化和粒度程度之间存在相关性。
而且，由于TDD从业者通常会避免在编写单元测试之间对代码进行任何重大更改，因此因不知道发生了什么而必须进行调试的机会会小得多。
5、正强化
现在来看看使用测试驱动开发最令人惊讶和最不为人所知的好处。
通过使用测试驱动开发，通过实际遵循短的红-绿-重构循环，你的大脑会得到大量的积极强化，这使得编程成为一项非常愉快的活动。事实上，看到你如何从一无所有到一些有用的东西，而且不仅是有用的东西，而且是经过充分测试的东西，真的很令人满意。
想想你写了几个小时的生产代码，然后调试和测试它，才发现现在你需要为你编写的代码编写单元测试，感觉真的很累！这真的很令人沮丧。
通过测试驱动开发，不会有这种程度的不满意。相反，你会得到持续的积极强化
TDD的缺点
那么，测试驱动开发有哪些缺点呢？老实说，我是TDD的粉丝和实践者，对我来说，找到驱动开发的真正且重大的缺点并不容易。我努力尝试，所以我想出了一些非常有趣的东西，我相信即使是经验丰富的开发人员也会感到惊讶。
1.需要额外的培训
首先，测试驱动开发需要培训。如果你不知道其机制是如何工作的，那么开始使用 TDD 并不那么容易，这需要一些额外的培训，即使对于高级工程师也是如此。
2. TDD不同流派之间的混淆
不同流派和测试驱动开发风格之间也存在混淆。有时，当人们争论测试驱动开发是好还是坏时，他们实际上不是在争论测试驱动开发作为一种现象，而是在争论测试驱动开发的特定流派，然后所有流派都有不同的目的，并且是针对不同的环境而设计的。
3. TDD并不保证能拿出最好的算法
使用 TDD 的另一个潜在缺点是，虽然测试驱动开发可以帮助你提出可行的算法，但它通常不能保证你提出有效的 AND/OR 有效算法。因此，如果你想编写精心设计的软件，学习算法和数据结构仍然非常重要。
因此，考虑到所有这些，测试驱动开发对于一次性代码或你实际上并不打算维护的代码来说可能有点过分了。也许，这就是你可能不想使用测试驱动开发的地方。
感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取
1101
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
