测试驱动开发：开发人员魔术棒
让我们讲一个故事。
“不久以前，我已经为即将上线的测试仪提供了我的应用程序的构建。 我已经对其进行了一些修复，根据我的开发人员健全性测试，这些构建已使生产准备就绪。 但是经过测试，情况完全不同。 在某些情况下，由于某些较早的修复程序，我遇到了错误。 搞什么鬼？？？ 除了使我的构建稳定之外，我使它更加不稳定。”
我不是唯一遇到这种情况的人，但是许多开发人员也遇到了这种情况。 那么我们该怎么做呢？ 答案是测试驱动开发（TDD）。
我们要学什么？
TDD上有很多博客。 我将列出您可以在其中找到的一些最佳参考。 我们不会讨论理论上的TDD概念，而是将重点放在我们如何从开发人员的角度计划实现TDD。
- 什么是TDD？
- 为什么选择TDD？
- 如何规划TDD？
- TDD的警告。
- 您需要TDD吗？
看起来太多了吗？ 不用担心，我们会做的很快而简短。 😉
什么是TDD？
测试驱动开发是美国软件工程师肯特·贝克（Kent Beck）提出的开发程序，在编写代码的同时，我们还记录了测试用例。 从而允许我们在继续开发的同时测试我们的代码。 下图描述了传统开发与TDD之间的区别。
在传统开发中，我们首先开发代码，完成功能并进行手动测试。 但是在TDD中，我们首先写下测试用例，然后相应地开发代码。 这有助于我们最大程度地减少代码失败或错误的机会。 如果不更新旧的测试用例，则开发的任何新功能也应尊重现有的测试用例。
TDD基于RGR的概念，即红色，绿色和重构。
红色：我们首先编写失败的测试用例。
绿色：我们编写通过测试所需的最少代码。
重构：如果需要测试代码，我们也会重构代码。
为什么选择TDD？
- 最大限度地减少代码失败的机会。
- 最小化团队中任何新开发人员在代码库上工作的机会。
- 由于引入了新功能或错误修复，破坏现有功能的机会较小。
- 提高产品知识。
- 改进编码标准。
如何规划TDD？
百万美元问题来了？ 我们都知道什么是TDD。
但是我们如何计划TDD？ 我们将如何决定需要编写哪些测试用例？ 我要编写并开发该功能，然后为它们编写测试还是将来如何？ 困惑？
了解正确实施的功能。
让我们以以下要求为例：
要求：
- 构建一个程序，该程序将从用户那里获取城市的人口输入，并返回该城市所属的类别。
- 以下是城市类型及其人口范围：
- 小（5,000至10,000）
- 中（10,000至50,000）
- 大（超过50,000）
将功能细分为子功能。 考虑到编程意义上的方法，这是对每个功能的破坏。
我们将整个实现分解为以下子功能：
- 从用户那里获取有关人口的输入。
- 准备一种对人口计数进行分类并通过自定义输出返回城市类型的方法。
预览 该功能 的 UML图 。 考虑将要构建的类，将用于满足要求的属性和方法。
我们可以具有以下类集，并对我们的类以及相关的属性和方法进行粗略估计。
defineCityType（）->包含用于根据人口确定城市类型的逻辑。
configureOutput（）->保存用于向用户配置显示的逻辑。
写下每个功能的测试用例。 每个子功能可以细分为功能。
现在，我们应该写下预测上述类图的测试用例。 为每个类及其功能编写测试是一个好习惯。 参照上面的UML图，我们要测试City和CityCategorizer的属性，还要测试defineCityType （）和configureOutput（）方法。
TDD的警告：
- 减慢了开发过程。
- 编写初始测试用例时，无法预测将来增强的复杂性。
- 如果需求经常变化，您将浪费大量时间来重新配置测试用例。
您需要TDD吗？
- 如果您的项目是短期项目，并且长期存在，那么您可能要避免使用TDD。
- 如果您的项目不可扩展，则应避免使用TDD。
- 如果您的项目是可扩展的并且具有庞大的代码库，则TDD效果很好。
参考文献：
维基百科
测试驱动开发简介
RGR
UML图
我很想听到你的消息
您可以通过以下渠道与我联系，以获取任何查询，反馈或只是想进行讨论：
Twitter — @G_ABHISEK
领英
堆栈溢出
邮件
abhisekbunty94@gmail.com
为了立即连接
SkypeId — gabhisekbunty
请随时与您的其他开发人员分享。