TDD 测试驱动开发
Kent Beck 提出的TDD。
TDD有三层含义：
Test-Driven Development
Task-Driven Development
Test-Driven Design
编码方式：
- 先分解任务，分离关注点
- 列 Example，用实例化需求，澄清需求细节
- 写test case，只关注需求，程序的输入输出，不关心中间过程
- 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可
- refactor，用手法消除代码里的坏味道
- 写完，手动测试一下。有问题补个用例，修复
- 转QA，有问题，补用例，修复
红：写一个失败的测试，它是对一个小需求的描述，只需要关心输入输出，这个时候根本不用关心如何实现。
绿：专注在用最快的方式实现当前这个小需求，不用关心其他需求，也不要管代码的质量多么惨不忍睹。
重构：既不用思考需求，也没有实现的压力，只需要找出代码中的坏味道，并用一个手法消除它，让代码变成整洁的代码
注意力控制
人的注意力既可以主动控制，也会被被动吸引。注意力来回切换的话，就会消耗更多精力，思考也会不那么完整。
使用 TDD 开发，我们要主动去控制注意力，写测试的时候，发现一个类没有定义，IDE 提示编译错误，这时候你如果去创建这个类，你的注意力就不在需求上了，已经切换到了实现上，我们应该专注地写完这个测试，思考它是否表达了需求，确定无误后再开始去消除编译错误。
好的单元测试应该符合几条原则：
- 简单，只测试一个需求
- 符合 Given-When-Then 格式
- 速度快
- 包含断言
- 可以重复执行
真的什么都会测吗？连 getter 和 setter 也会测试吗？
Kent Beck 说：公司请我来是为了实现业务价值，而不是写测试代码。
所以我只在没有信心的地方写测试代码。
TDD 要不要做提前设计呢？
Kent Beck 不做提前设计，他会选一个最简单的用例，直接开写，用最简单的代码通过测试。逐渐增加测试，让代码变复杂，用重构来驱动出设计。
TTD中要求写完一个test case后，在代码里做到快速实现。我觉得这一点也很关键。先用hard code做出来，然后测试通过后，再去关注具体实现。代码的每次改动后就跑一次测试。完全省去了，写完一长串代码后，跑不起来，再加断点debug省时间和精力。
实例请参考：
https://www.jianshu.com/p/62f16cd4fef3
在视频里看到现场写代码，才能对TDD有形象和深刻的理解
转载于
//www.cnblogs.com/Gift/p/10344982.html
悠悠
忘是亡心i
左手的ㄟ右手
ゞ 浴缸里的玫瑰
系统管理员
还没有评论，来说两句吧...