TDD training summary

从加入TW的第一天Pair开始就在项目中实践TDD。前一段时间阅读了Kent Beck的<<TDD by Example>>，之后对书中的内容进行了总结 。这次，同事yuheng 给咱们两个项目组以Code Kata的形式进行了一次TDD培训。通过这次实践结合理论的培训，自己进一步加深了对TDD的理解，可谓收获颇丰。

 

为什么要TDD？TDD有什么优缺点？

优点：

1. TDD可以让设计的接口清晰，更大程度地保证的模块内部的高内聚性和模块间的低耦合性

2. 提高系统的测试覆盖率，避免系统先开发后不可测试的现象。

3. 小步前进，快速反馈。

问题：

1. TDD驱动出来的实现是否会缺少对整个系统架构的设计，缺少全盘统一规划？

TDD与系统架构，系统设计并不矛盾，并不是说用了TDD就不能有系统架构。可以针对系统的业务需求规划系统架构，再在这个基础上进行TDD开发。但一定要避免过度设计。


TDD的过程中维护TODO List
Tasking是一个分而治之的过程。从大的方面来说，一个业务系统的开发可逐步划分成：系统，Release, Master Story, Story. 而TDD过程中维护的TODO List主要是针对

一个Story开发过程中的任务切分。同《TDD》中描述的一样，在Story开始时，我们应该对它作一个任务列表，随着任务的向前推进不断地更新任务状态，也随时可以往列表中添加新的任务。

测试用例设计
TDD的过程中应该合理的设计测试用例。设计测试用例的方法包括：等价类划分，边界值，因果图，正交方法，Pairwise方法等。

从外向内还是从内向外TDD
两种方案分别适用于不同的场景。
从外向内是从系统或模块的最外层接口出发，逐步驱动出内部的设计。之后再TDD驱动内部各个模块的实现。
从内向外通常会对系统进行架构设计，划分各个模块的职责。然后再TDD驱动各个模块的实现。最后将各个模块进行集成。
条件允许的情况下，个人倾向于从外向内进行TDD。它的优点在于能保证驱动出的各个模块能顺利集成，满足最终系统的需求。但是对于一些大型系统，很难在一开始就会有最外层的集成环境，所以只能先系统架构进行模块划分。


从核心功能开始，优先实现系统的业务价值高的核心功能。

Mock方法
首先，要弄清楚一些mock相关的名词，如mock, stub, spy, dummy, fake等。
使用Mock方法时要划分"System under test" (SUT) 的边界，避免测试边界外的功能。