51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

查看: 521|回复: 0

[原创] 补充单元测试你知道如何开始吗?

[复制链接]

该用户从未签到

发表于 2022-9-22 15:10:55 | 显示全部楼层 |阅读模式
单元测试应该及时编写,就算没有实践TDD,也应该在代码实现之后尽快编写单元测试,避免写出不可测试的代码,也可以让bug尽早暴露。
  但很不幸的,我们很多时候在刚开始卓越工程,推广单元测试的时候,不得不面对补充单元测试的情况;这绝对是一个有挑战的事情。

  补充单元测试应该从哪里开始?参考测试金字塔,对于基础组件库来说,可以根据具体情况来定。

  对于业务库来说,第一步建议从金字塔顶端的测试:

  ·优先覆盖回归测试用例中P0级别的用例;

  · 避免过度指定的端到端测试;

  · 适当的契约测试;

  接下来,从金字塔中间层开始,不断向上、向下补充。

  可测试的设计
  应当容易、快速地为一段代码编写单元测试;可测试的设计,使我们写出模块化的设计。

  行动指南

  为了写出可测试的代码,需要注意以下几点:

  1、避免复杂的私有方法;

  2、避免final方法;

  3、避免static方法;

  4、使用new要当心;

  5、避免构造函数中包含逻辑;

  6、避免单例;

  7、组合优于继承;

  8、避免服务查找;

  9、基于接口的设计;

  可测试的代码是否违背了SOLID中的开闭原则?

  可测试的代码设计,有的时候需要避免复杂的私有方法或者受保护的方法,因为这些意味着不可测试。

  这样的话是不是意味着可测试的设计违反了开闭原则呢?

  在代码重构的时候,可以认为给对象模型增加了另外一种最终用户——测试用户。

  另外如果一部分代码实在不希望暴露,也可以使用@visibleForTesting 修饰。

  单元测试与重构

  写单元测试的过程往往伴随着重构;代码重构同样需要单元测试保证代码正确运行。

  重构需要遵守的纪律:无测试重构无意义,频繁重构、果断重构、坚决重构。

  持续重构

  将麻烦扼杀在摇篮。

  果断重构

  敏捷编程的名言之一。规则很简单:重构时要勇敢。勇敢尝试,勇敢修改,不用害怕代码。

  让测试始终能通过

  建一个绿色安全区,不允许破窗出现。

  留条出路

  仓库打好tag,以便在需要的时候能够回滚。

  可测试的代码

  可测试的代码就是解耦了的代码;可测试的代码帮助我们实现更好的抽象。

  做不到TDD,可以做到测试先行

  下图是遵循TDD三大法则的实践过程;TDD很强大,但不一定适用所有的团队,推广难度很大,学习曲线很高。



TDD事实上由两个方面组成:测试先行,以及演进式设计;测试先行是非常重要的工程实践,做不到TDD,可以做到测试先行。

  在Kent Beck的经典名著《解析极限编程》中,提到:尽早测试,经常测试,自动测试!

  测试先行的本质能力要求是接口的设计能力——能否清晰的定义出设计单元的边界。

  如何理解单元测试代码覆盖率

  不要把它们变成管理的指标。

  这就是你使用覆盖率数字的目的:使用它们作为衡量标准来帮助你改进,而不是用它们作为惩罚团队和使构建失败的棍棒。 ——《匠艺整洁之道》

  代码覆盖率的一大忌讳:为了追求代码覆盖率,只测试不进行验证;

  一味追求代码覆盖率,往往写出无效的单元测试,额外增加了维护成本,最终不得不放弃以失败告终。

  与其追求代码覆盖率,不如将重点关注在确保写出有意义的测试。

  沉淀最佳实践

  必须承认单元测试有一定的成本,成本曲线来看,前期比较高;恰恰是这前期的门槛,让很多人望而却步。在团队内推广的时候,最难的就是写出第一个单元测试;

  我们需要沉淀最佳实践,帮助降低写单元测试的成本,让我们更容易地写出有效的单元测试。

  我觉得沉淀最佳实践最好的方法,就是Code Review;正如我们前面所说的,要把单元测试当成是“一定公民”,在Code Review的过程中,互相学习、分享最佳实践,消除无效的单元测试。

  隔离单元测试与集成测试

  集成测试是对一个工作单元进行的测试,这个测试对被测试的工作单元没有完全的控制,并使用该工作单元一个或多个真实依赖,例如时间、网络、数据库、线程或随机数生成器等。

  任何测试,如果它的运行速度不快,结果不稳定,或者要用到被测试单元的一个或多个真实依赖,就是集成测试。

  在日常开发过程,我们需要建一个绿色安全区:单元测试与集成测试隔离;

  集成测试不够稳定,运行时间长等问题,如果不做隔离,日常开发浪费时间和精力维护,最后导致开发人员不再信任测试。

  单元测试与ABTest

  单元测试与ABTest有什么关系吗?事实上没有什么关系。但一定程度程度上,它们本质是相同的,都是保障线上代码质量(当然单测的成本,对于基建、开发者的能力的要求更高);


  在日常开发中,经常主动为新的代码逻辑增加AB开关,一旦线上出问题留一条后路;发生问题的时候往往感慨AB开关救我一命;

  单元测试可以让问题左移,防止问题上线,同样是一道保护;

  如果有一天团队同学愿意主动增加单元测试来保护自己的代码,那么单元测试这件事就算比较成功了。




本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-3-29 23:16 , Processed in 0.062254 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表