测试用例全面地覆盖TC中的测试点，有了这层保障，开发可以放心地去编码了，测试同学同时把want.fail（）方法改成具体的校验点。

　　TDD第二步：让测试用例跑通

　　比如针对testAddProductFail_NoProductId()方法，写具体的测试代码和校验点，

　　对ProductDo的其它字段set相应正确值，ProductId设置为空，调用相应service的AddProduct方法，对返回结果做判断。

　　测试同学一一完善各个测试用例。。。

　　在这一步骤中，由于测试点校验部分需基于接口内部实现定义ok，所以测试可能仍会滞后开发，但项目中接口数肯定是有很多的，所以每开发完一个接口，测试可以立马写几个测试用例，并行度依然较高，这一点也充分体现了测试向前，把可以做的都提前做掉了

　　在hudson中每天运行持续集成，观察test的成功个数曲线，正常的趋势是：先一路上升，后逐渐平坦，后稳中有升。

　　TDD第三步：开发优化代码

　　当所有的测试用例都pass，那么产品方提出的业务需求基本满足了，自动化测试case的基本保障也已经建立了。这个阶段，测试同学去做后续各种工作了，那么开发同学的时间资源也宽裕了，回头审视优化自己的代码，有自动化回归保障，重构也没那么可怕了，测试的工作也真的发挥了持久价值而不是一次性劳动。后续测试过程中保险起见还是会做一个简单的手工测试回归，但遇到的问题真的非常少了

　　三步走完，项目也over了。测试-编码-重构，这个过程做起来并没有想得那么难推进那么痛苦，反而项目组氛围融洽了，大家每天都会为新增的用例数和上升的覆盖率开心，也会为谁提交的代码导致了失败而互相调侃，测试也不用婆婆妈妈跟在后面催了。。

　　三、心得

　　TDD模式下自己的几点体会

　　1、测试向前，参与度更高。传统方式下，测试在项目前期完成tc设计评审后，只能空置等开发完成代码，部署环境后才能开始测试。更深入来说，不了解开发进度，不了解具体实现，更无从谈起指导开发过程。TDD则让测试全程参与到项目过程中，也能通过接口数和覆盖率变化去量化了解度量项目进度；

　　2、对需求变更的响应度更高。当有需求变更，需要增加或者变更接口时，修改了代码只要保证测试用例通过，可以提交了，而不一定要启动环境去验证。

　　3、持续集成和TDD是绝配。看着hundson上的测试用例渐渐变绿，直到某一刻整个工程都变蓝，再看着代码覆盖率由30%到50%到。。正能量和成感会持续递增。。

　　如果再集成上次web组周会上傅雷同学分享的eXtreme Feedback Panel 插件，弄个大的液晶面板显示到项目组成员的眼前，那每天的工作更有奔头了^_^