背景：
- 重新阅读了以下 可以引发思考 的 陈年老文
之所以要 “叕” 谈 TDD， 除了上述背景，也是因为自己工作4年来，虽然经常听到 TDD，但着实没有“完整” 的在项目上实践过它。直到最近打算在当前的交付项目上实践，才又重新审视它，以求回答下列问题：
在逐一回答这些问题之前，先说我对 TDD 这种实践的 观点：
- TDD 是确保 Dev 在编写代码时，处于 对需求保持 “清醒（Obvious）” 状态 的方式之一，但并非 唯一 方式
- TDD 中的测试（T）要面向业务需求，而非代码实现
- TDD 是一种 快速， 可复用 的 反馈获取 方式，而非唯一方式
- 如果能 不用 TDD 并做到上述 3 点，那么不 TDD 也没问题。
何为 TDD
在工作的这 4 年来，我对于 TDD 的认识也在不断变化，现在看来，这种变化的趋势 是 从 关注实践形式 向 关注实践目的 的演变。
那么回到这个问题，Wikipedia 上看到的 解释 如下：
Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.
ps: 我没有采用百度百科给出的解释，因其有局限性。它将 Test 缩小到了 Unit Test, 这并不贴切, 我认为测试驱动开发的测试应和测试金字塔相关，可能涉及多层。
我认同这里从 TDD 的 实践形式 角度给出了答案：
- 将 需求 转化为 测试用例
- 测试 先于 开发
- 所有的 产品代码 都能被 反复运行 的 测试 所检测
在上述的实践形式中，隐藏了这样两个关键点：
- 需求转化为 测试代码 要先于 产品代码
- 所有的 产品代码 都会被 测试代码 覆盖
在逻辑上，1和2 之间是因果关系。
遗憾的是，大多接触 TDD 的新人，都会更看重 结果（2），并且结果也更容易被一些辅助工具所衡量。但是，产生结果的原因（1），却经常被忽视，因此产生了一些”奇怪“的疑问：
- 单元测试的粒度要多细？
- 测试覆盖率多少才算达标？
- 应该关注行覆盖率，还是分支覆盖率？
当 开发者 开始关注 将需求 直接 转化为 测试用例代码 时，上述的所有问题都会被迎刃而解：
- 需求所对应 的 成功用例、失败用例、需要考虑的边界条件等等，所有的这些用例可能会被分散在测试金字塔的不同层，其粒度也就结合不同层的关注点被划定了。
- 当测试用例已经将所有需求都覆盖到了，那么能通过所有测试的产品代码的 覆盖率 还重要吗？
下一篇《“叕”谈TDD（二）--- 为何TDD》中，我将从TDD的实践目的角度给出我的看法。
