你是否还在用如下这种方式编写代码？
- 需求分析，想不清楚细节，管他呢，先开始写。
- 发现需求细节不明确，去跟业务人员确认。
- 确认好几次终于写完所有逻辑。
- 运行起来测试一下，靠，果然不工作，调试。
- 调试好久终于工作了。
- 转测试，QA 测出 BUG，打补丁。
- 终于，代码可以工作了。
- 一看代码烂的像坨屎，不敢动，动了还得手工测试，还得让 QA 测试，还得加班。
我要介绍的 TDD 编码方式是这样的：
- 先分解任务，分离关注点。
- 列 Example，用实例化需求，澄清需求细节。
- 写测试，只关注需求，程序的输入输出，不关心中间过程。
- 写实现，不考虑别的需求，用最简单的方式满足当前这个小需求即可。
- 重构，用手法消除代码里的坏味道。
- 写完，手动测试一下，基本没什么问题，有问题补个用例，修复。
- 转测试，小问题，补用例，修复。
- 代码整洁且用例齐全，信心满满地提交。
本场Chat内容包括：
- TDD 的几层含义；
- TDD 的本质；
- TDD 的好处；
- 为什么大部分人 TDD 会失败；
- TDD 的正确练习路径。
实录提要：
- 在一个团队中谁来写单元测试呢，开发还是测试？如何协作？
- TDD 是否适合界面的开发？
- 有关于怎样分解任务的策略，拿到一个任务，如何开始第一步？
- 如何在紧张的工期和完善的单元测试之间进行权衡？
- 两周一个版本迭代，适合用 TDD 吗？
- 对于单元测试的 mock，应该针对外部接口进行 mock 吗？
阅读全文: http://gitbook.cn/gitchat/activity/58aea58573bbf56f08a092e7
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。
