单元测试之难

自动化单元测试需要基于一些成熟的单元测试框架。主流的编程语言都有:Java的JUnit,C++的CppUnit等等。以C++为例,编程人员编写代码时,需要同时编写测试套,通过C++宏来控制基于真实代码编译/运行,或只是单元测试。
单元测试的一个难点是测试覆盖率,要达到100%的语句覆盖率是很难,同时也是没必要的。因为一些异常保护的分支是很难运行得到的,例如分配内存失败的异常保护分支。
另外一种观点是:100%的语句覆盖率还不足以保证代码的正确逻辑,语句覆盖之上,还有条件覆盖、路径覆盖。条件覆盖是指:如果一个条件判断语句由三个表达式组成,那么最多要有6个用例才能达到对所有真假条件的判断。因为代码由多个分支组成,以两个条件判断、每个条件判断两个分支为例,要4个用例才能达到路径覆盖。这是一种理想化的要求,这是非常困难的,同时也是没有自动化评估手段的,只能靠人工检查。
单元测试的另外一个问题是:很多的代码都依赖于外部的运行环境,如数据库连接、外部文件操作等,因此需要大量的条件宏判断来区分真实环境运行或单元测试环境运行。当然,这也体现了单元测试的定位和局限性:它只是用来验证代码的内部正确性的,至于和外部的接口,必须通过集成或系统测试才能完成。这个局限性也一定程度上影响了开发人员努力设计、执行更多单元测试用例,并提高测试覆盖率的积极性。因为再全面的单元测试覆盖率也不能完全说明代码的运行正确性,何不把更多的精力放在集成和系统测试上?

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值