培训测试驱动开发有感

由于所在的公司是互联网行业，很少接触到软件工程的概念，所以对于测试驱动这样的开发模式一直不感冒。由于本次项目中需要用到测试驱动开发来进行，就去听了测试驱动开发的培训，感触颇深

测试驱动开发的一般流程是：

快速新增一个测试

运行所有的测试（或者你自己新增的单元测试）

发现新增的单元测试不能通过（因为没有写代码），对代码进行一点点修改，需要尽快让测试代码通过

再次进行运行所有的测试，并且全部通过

重复3，4过程

对完成的代码进行重构，再次运行所有的测试

简单的一点就是 新增测试用例->修改代码->运行测试用例->在修改代码->运行测试用例->测试用例通过->重构

其中几个细节点：

对于未实现的方法，不要返回默认值，抛出异常 例如UnsupportedOperationException

可测性>封装性 ，尤其是内的内部状态或者内部方法需要测试时，要提供一个get方法获取内部状态，要么暴露把变量声明为public，而方法需要声明为public

采用测试驱动开发，一定会增加成本。测试驱动开发对于未来的重构有帮助。当产品的生命周期越长，这种开发模式的优势越明显，价值也越大。对于一个不断持续开发的产品来说，测试驱动开发前期投入会非常大，后期维护成本会逐步降低。如果对于生命周期很短的产品，比如一个营销活动开发的代码，由于后期很少会对其修改，则测试驱动开发的价值就比较低

测试驱动开发对后期的技术重构会有很大的帮助，但是对于业务重构的价值帮助不大。因为整个业务模式有了很大的变化，相当于重新开发了一套产品。测试用例全部都要重新实现

当单元测试覆盖率在60%以下的时候，对于整个项目的质量没有太大的帮助。因为项目主要的流程部分编码占整个项目编码的60%，而这一部分会进行重复性的测试。当单元测试覆盖率达到90%的时候，才能越来越多的发现许多隐藏很深的bug。

分支覆盖率重要性大于代码行覆盖率

先写代码，在补写用例的不是tdd开发模式。