单元测试之难

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
单元测试不使用mock的情况下,将会调用真实的依赖对象。这可能导致以下几个问题: 1. 效率低:如果依赖对象的操作需要访问数据库、网络或其他资源,那么在每次运行单元测试时都会涉及到这些操作,从而增加了测试的执行时间。 2. 不稳定性:依赖对象的行为可能会受到外部因素的影响,例如网络连接的不稳定性、数据库中数据的变化等。这会导致测试结果的不确定性,使得测试变得不可靠。 3. 难以控制:某些依赖对象的行为可能很难模拟或控制,例如,如果依赖对象是一个第三方库或在测试环境中不可用的服务,那么就无法直接对其进行测试。 因此,使用mock对象可以解决上述问题。通过创建模拟对象来替代真实的依赖对象,我们可以控制模拟对象的行为,使其返回我们期望的值,而不需要真实地执行依赖对象的操作。这样可以提高测试的效率、稳定性,并且更容易管理和控制测试环境。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* *2* *3* [单元测试之mock使用](https://blog.csdn.net/wohiusdashi/article/details/124085245)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 100%"] [ .reference_list ]

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值