如何写出有效的单元测试?

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

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

  • 优先覆盖回归测试用例中P0级别的用例;
  • 避免过度指定的端到端测试;
  • 适当的契约测试。

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

可测试的设计

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

行动指南

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

  • 避免复杂的私有方法;
  • 避免final方法;
  • 避免static方法;
  • 使用new要当心;
  • 避免构造函数中包含逻辑;
  • 避免单例;
  • 组合优于继承;
  • 避免服务查找;
  • 基于接口的设计。

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

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

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

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

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

单元测试与重构

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

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

持续重构

将麻烦扼杀在摇篮。

果断重构

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

让测试始终能通过

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

留条出路

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

可测试的代码

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

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

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

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

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

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

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

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

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

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

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

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

沉淀最佳实践

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

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

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

隔离单元测试与集成测试

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

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

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

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

单元测试与ABTest

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

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

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

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

写在最后

从软件工程到卓越工程,单元测试从可选变成了必要;想要实现主干开发、大库模式,单元测试是前提条件。

关于单元测试这件事,我觉得最重要永远是写单元测试的人,优秀的团队文化非常重要,没有什么能够真正衡量单元测试做的好坏,有的只是程序员的职业操守。

我们花了很大的篇幅讨论有效单元测试的重要性以及如何写出有效的单元测试,不得不承认单元测试有一定的成本,真正实践依然需要很多的路要走,需要我们在实践中定义好单元测试的边界,找到最适合团队的最佳实践。

上一页123下一页


留言