之前经历过一个自己觉得挺有意思的项目，对一直从事枯燥技术活的测试同学来说，一瞬间还是被点燃起激情了，大致描述下在这个项目中是如何运用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();