如果您问我从肯特·贝克（Kent Beck）2003年的书中学到的关于测试驱动开发的最意外的事情是什么，那么我将确切地知道该怎么回答。 它也可能会让您感到惊讶，所以跳进去，让我们尝试从另一个角度看一下。
当您第一次听说TDD时，您如何看待它？
我记得这种感觉很好：这是“不，你不能认真对待，我该如何测试我什至还没有实现的东西？”的混合体，一种呆滞的感觉，“上帝，编写测试是太难了”和一点点耻辱，因为“优秀的程序员会执行自动化测试”，而我根本没有做太多的测试。
大概是十年前，那时我还在大学三年级，几乎没有任何“工业”经验。 TDD和其他敏捷思想正朝着阻塞软件开发流程的现代问题发展，这远非俄罗斯计算机科学专业的学生所理解。
TDD还对在实际项目中在地球上如何可行提出了疑问。
那你为什么决定读这本书？
几年后，我找到了我的第一份“工业”工作：那是一家俄罗斯大型互联网公司的测试软件工程师。 在很短的时间内，我看到了许多质量各异的代码，这些代码大多数时候都在巨大的负载下工作，并为公司带来了可观的收益。
我主要从外部探索代码，因为我最关心的是如何调用返回用户得分的服务，或者如何使数据处理守护程序以单进程模式启动，以便其行为至少在可预测期间可预测。测试。
但是我也偶然地窥视了内部。 我应该说这在大多数情况下是结构不良，难以理解的–塔达！ -没有单元测试？
我对自己问的问题是，TDD似乎很有道理，为什么不将其应用于此处？ 离开后，我去寻找答案-在书的页面上。
最后，最出乎意料的是什么？
贝克在书中很早就指出，TDD的基本过程大致上是重复以下步骤：
- 红色测试：针对新功能编写测试，并确保它们不会失败
- 绿色测试：编写足够的代码以使测试通过
- 重构 ：清理代码
红色和绿色的步骤非常明显，但是第三个步骤根本不明显。 这是什么意思？ 为什么甚至还有重构？
我对本书的重构有什么了解
简而言之，重构就是在您更改代码但系统的外部行为不变的情况下。
但是对于我是的初级软件爱好者来说，它却具有不同的风味：
将这些无法维护的旧代码重写为更易于维护的代码。
这种情况在我们程序员之间很常见。 您去年编写的一个CS类项目，今年想重用于另一个项目：您好，过去的我，您疯了吗？ 你为什么写那个垃圾？ 或一个寿命长达数年，维护人员变更了几次的工业项目，却没人真正知道那里发生了什么。
任何状况之下：
–推荐人！
当问题已经存在时，通常会想到这个主意。
重构对TDD意味着什么？
TDD允许您编写愚蠢的代码-记住，足以通过测试。 它使您的双手松开：如果有简单的方法可以做某事，那就去做。
复制粘贴？ 就是这样
硬编码值？ 听起来不错。
有人会说，我们一直在软件工程中这样做。 但是在TDD中，它是行为准则，以及数字3：重构。
在此阶段，您将从代码中删除意外的“快捷方式”。 复制？ 概括，但足以通过测试。 硬编码的值重复吗？ 使一个常数。 重构对您的代码的作用在于，它为将来的更改做好了准备 。
为什么能够进行测试和重构如此重要？
“ TDD示例”一书应该说服您的一件事是，您的代码注定要更改。 在这种情况下，最好进行测试并经常重构。 因此，无论何时更改，无论是在五分钟或五个月后，是修复拼写错误或重新设计体系结构，您都已做好准备。
应该失败的测试将会失败，那些应该失败的测试不会失败，并且将确保您的软件坚如磐石。 您的测试足够并通过 。
您的数据结构可以充分表示数据，并且可以安全地重命名，移动，拆分，重组代码，并确保所修复的错误不会引入一百个新错误。
因此，测试驱动开发的关键特性不是测试，而是自信地进行更改的能力。 使用TDD，您可以从小做起，拍摄星星！
一件事：我们如何开始在遗留项目中进行TDD？
我首先将其吸收。这个问题实际上产生了一种炸弹爆炸效果：一个人如何响应THAT？
在这里，我们接近理解为什么TDD不是灵丹妙药。 这是非常严格的，因此，一旦您一点点不遵守，就会根本不遵守，并失去大部分收益。 如果您尝试在旧版软件项目中使用TDD，就会发生这种情况。 达到所需的测试覆盖范围水平将花费大量时间-并且在此之前无法进行安全的重构。
从测试开始。 根据需要写尽可能多的东西。 尝试不同级别的测试，任何能胜任的工作。 为新功能编写测试。 赞美写作测试，并评估实现该功能所需的工作，包括正确测试该功能所需的时间。
一旦陷入困境，无论是在绿色之前还是之后红色都无关紧要。
安全的变化是最重要的。
