之前经历过一个自己觉得挺有意思的项目，对一直从事枯燥技术活的测试同学来说，一瞬间还是被点燃起激情了，大致描述下在这个项目中是如何运用TDD思路来尝试的。
TDD其实都不陌生了，关于它的介绍也很多，不同角度出发，每个人理解也不尽相同。自己比较认同《测试驱动开发的艺术》中对TDD的6字总结：测试-编码-重构。
实践证明，我们的操作方式也就是先写测试用例，然后为了让用例跑通去写实现代码。用例全部pass后，再根据时间和资源情况逐步优化代码。
一、项目背景
项目之所以能实践TDD，也算天时地利人和了。
1、当时部门业务方向待定，时间和资源相对宽松，有实践机会。
2、开发团队质量意识和配合度很高。开发和测试想法一致都想创新玩一次。
3、项目类型比较适合TDD。小步快跑常迭代的敏捷型项目，TDD可以带来诸多好处。
项目主要功能点：
Ps：系统的名称和代码就隐掉不具体列出了。。
1、在一个后台xx管理系统中，完成对某种类型产品的管理，包括商品录入，编辑，查询，删除，上下架等基本功能。
2、监控功能。监控产品的售卖过程中的不正当定价；监控产品xxx情况；记录并进行处理等。。。
二、项目过程中TDD实践
TDD前期依赖：
TDD实践需依附前期设计阶段一个重要的产出文档——接口描述文档。包含接口名、类名、方法名等内容描述。
这个需加到项目流程中，也需开发同学的配合。这个文档的输出，其实也是利于开发工作效率提升的，因为基于接口层面的描述和定义是最清晰的。换位思考下，到了编码实现阶段，我做为一名开发，让我提供一个新增xx产品的接口，应该会比完成新增xx产品这个功能的XX部分来得更明确和清晰。所以，作为QA需和开发同学沟通一致，大家一起维护这份文档，保持信息的对称。那么后续阶段里，项目共涉及多少个接口，完成多少个，待完成多少个，也一目了然了。
接下来，测试同学就基于这个文档编写测试case桩，践行TDD了
TDD第一步：编写测试代码
测试设计测试用例，开发设计框架和接口，完成后，在工程中添加测试桩。针对app层+service层+dao层大家分工添加。
这时添加的测试桩都是空方法，先让它失败，
ps.以添加商品举例，根据方法命名可以大概清楚用例涉及的场景
eg.
| public void testAddProductSuc_WithPrice(){ want.fail(); } |
添加商品测试场景有以下这些：
size，spuId，productId，shopId为必填项，price未非必填项，那么添加完的测试桩实际就对应一个个测试用例：
成功场景：
| testAddProductSuc_All(); testAddProductSuc_NoPrice(); |
异常场景：
| testAddProductFail_NoSize(); testAddProductFail_NoSpuId(); testAddProductFail_NoProductId(); testAddProductFail_NoShopId(); |
