TDD 测试驱动开发
前言
好的开发模式
好的开发模式，帮助开发者在编写生产代码的时候，处在一种高认知的状态。
也就是说，开发者处于 obvious 的状态，对自己编写的代码有清晰的认知，才能更好的编写生产代码。
TDD（Test-Driven Development），就是这么一种让开发者处于 obvious 的的方法论之一。
坏的开发模式
开发者对整体系统的代码失去了上下文的联系，只能小心翼翼的修改代码，害怕破坏代码的平衡产生bug，步履维艰。
举个例子：
比较传统的开发模式是DLP（debug later programming），也就是先编程，编程完毕再debug。
这种对与个人而言，可能影响不大。但是对于团队，可能就是一个灾难性的打击。
比如在公司工作两年的一个开发人员离职，他编写的系统由下一位继任者接手的时候，可能就会造成继任者的头疼。
继任者完全不敢大刀阔斧的修改，只能让代码能跑就行，然后就按照自己的规范写。
结果就是，代码越写越乱，传说中的代码屎山（shit code），就是这么一代代员工的交替产生的（你拉一坨，我拉一坨）。
TDD
概论
以下解释来自百度百科
TDD是测试驱动开发（Test-Driven Development）的英文简称，是敏捷开发中的一项核心实践和技术，也是一种设计方法论。TDD的原理是在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代码。TDD虽是敏捷方法的核心实践，但不只适用于XP（Extreme Programming），同样可以适用于其他开发方法和过程。
TDD 准备阶段
主要是三个步骤
1.首先是得到需求，当然这个需求肯定是 complex 的（也就是开发者不能一下子理解的）
2.将需求拆分成一个个 obvious（也就是说开发者自己理解的方式）的任务列表（tasklist）
3. 将任务列表上的每个任务转换成一个或者多个测试，测试能在非常短时间内完成，比如15分钟
该流程容易出现的一个问题就是，1 很难转换成 2，主要两个原因：
一、需求理解不到位，此时需要向 BA（PM）澄清需求
二、技术限制，需要一定的时间去 spike 新的技术
TDD 代码阶段
将准备阶段得到的一系列测试，按照如下步骤：
- 在一系列测试中，取出一个未实现的测试，先写好测试逻辑（基本都是单元测试）
- 编写符合测试的生产代码（可以称之为代码草图，可以随意写）
- 使用步骤1的测试代码，测试生产代码，如果失败则返回步骤2，成功则继续下个步骤
- 重构优化逻辑代码，返回步骤1
