培训测试驱动开发有感

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

 

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

  1. 快速新增一个测试
  2. 运行所有的测试(或者你自己新增的单元测试)
  3. 发现新增的单元测试不能通过(因为没有写代码),对代码进行一点点修改,需要尽快让测试代码通过
  4. 再次进行运行所有的测试,并且全部通过
  5. 重复3,4过程
  6. 对完成的代码进行重构,再次运行所有的测试

 

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

 

其中几个细节点:

  1. 对于未实现的方法,不要返回默认值,抛出异常 例如UnsupportedOperationException
  2. 可测性>封装性 ,尤其是内的内部状态或者内部方法需要测试时,要提供一个get方法获取内部状态,要么暴露把变量声明为public,而方法需要声明为public
  3. 采用测试驱动开发,一定会增加成本。测试驱动开发对于未来的重构有帮助。当产品的生命周期越长,这种开发模式的优势越明显,价值也越大。对于一个不断持续开发的产品来说,测试驱动开发前期投入会非常大,后期维护成本会逐步降低。如果对于生命周期很短的产品,比如一个营销活动开发的代码,由于后期很少会对其修改,则测试驱动开发的价值就比较低
  4. 测试驱动开发对后期的技术重构会有很大的帮助,但是对于业务重构的价值帮助不大。因为整个业务模式有了很大的变化,相当于重新开发了一套产品。测试用例全部都要重新实现
  5. 当单元测试覆盖率在60%以下的时候,对于整个项目的质量没有太大的帮助。因为项目主要的流程部分编码占整个项目编码的60%,而这一部分会进行重复性的测试。当单元测试覆盖率达到90%的时候,才能越来越多的发现许多隐藏很深的bug。
  6. 分支覆盖率重要性大于代码行覆盖率
  7. 先写代码,在补写用例的不是tdd开发模式。