王争《设计模式之美》学习笔记
编写可测试代码案例实战
测试类
- Transaction 是经过我抽象简化之后的一个电商系统的交易类,用来记录每笔订单交易的情况。
- execute() 函数负责执行转账操作,将钱从买家的钱包转到卖家的钱包中。
- 在execute() 中,真正的转账操作是通过调用 WalletRpcService RPC 服务来完成的。
- 在execute() 中,还涉及一个分布式锁 DistributedLock 单例类,用来避免 Transaction 并发执行,导致用户的钱被重复转出。
测试用例
- 正常情况下,交易执行成功,回填用于对账(交易与钱包的交易流水)用的 walletTransactionId,交易状态设置为 EXECUTED,函数返回 true。
- buyerId、sellerId 为 null、amount 小于 0,返回 InvalidTransactionException。
- 交易已过期(createTimestamp 超过 14 天),交易状态设置为 EXPIRED,返回 false。
- 交易已经执行了(status==EXECUTED),不再重复执行转钱逻辑,返回 true。
- 钱包(WalletRpcService)转钱失败,交易状态设置为 FAILED,函数返回 false。
- 交易正在执行着,不会被重复执行,函数直接返回 false。
实现测试用例1
- 向类Transaction 中赋值buyerId、sellerId、productId、orderId,执行transaction.execute()。
- 此用例有以下四个问题:
- 如果要让这个单元测试能够运行,我们需要搭建 Redis 服务和 Wallet RPC 服务。搭建和维护的成本比较高。
- 我们还需要保证将伪造的 transaction 数据发送给 Wallet RPC 服务之后,能够正确返回我们期望的结果,然而 Wallet RPC 服务有可能是第三方(另一个团队开发维护的)的服务,并不是我们可控的。换句话说,并不是我们想让它返回什么数据就返回什么。
- Transaction 的执行跟 Redis、RPC 服务通信,需要走网络,耗时可能会比较长,对单元测试本身的执行性能也会有影响。
- 网络的中断、超时、Redis、RPC 服务的不可用,都会影响单元测试的执行。
- 通过继承 WalletRpcService 类,并且重写其中的 moveMoney() 函数的方式来实现 mock。
- 通过 mock (见下文:mock)的方式,我们可以让 moveMoney() 返回任意我们想要的数据,完全在我们的控制范围内,并且不需要真正进行网络通信。
- 因为 WalletRpcService 是在 execute() 函数中通过 new 的方式创建的,我们无法动态地对其进行替换。也就是说,Transaction 类中的 execute() 方法的可测试性很差,需要通过重构(见下文:重构 Transaction 类)来让其变得更容易测试。
- 重构后在单元测试中,使用依赖注入,非常容易地将 WalletRpcService 替换成 MockWalletRpcServiceOne 或 WalletRpcServiceTwo 传入 setWalletRpcService() 中。
- RedisDistributedLock 的 mock 替换。
- RedisDistributedLock 是一个单例类。单例相当于一个全局变量,我们无法 mock(无法继承和重写方法),也无法通过依赖注入的方式来替换。
- 如果 RedisDistributedLock 是我们自己维护的,可以自由修改、重构,那我们可以将其改为非单例的模式,或者定义一个接口,比如 IDistributedLock,让 RedisDistributedLock 实现这个接口。接下来我们就可以用前面的方法 mock 替换。
- 但如果 RedisDistributedLock 不是我们维护的,我们无权去修改这部分代码,可以对 transaction 上锁这部分逻辑重新封装一下(见下文:重新封装transaction 上锁)。
- 这样,我们就能在单元测试代码中隔离真正的 RedisDistributedLock 分布式锁这部分逻辑了。可以调用 transaction.setTransactionLock()。
- 我们通过依赖注入和 mock,让单元测试代码不依赖任何不可控的外部服务。完成测试用例1。
mock
- 所谓的 mock 就是用一个“假”的服务替换真正的服务。mock 的服务完全在我们的控制之下,模拟输出我们想要的数据。
- mock 的方式主要有两种,手动 mock 和利用框架 mock。
- 利用框架 mock 仅仅是为了简化代码编写,每个框架的 mock 方式都不大一样。
重构 Transaction 类
- 应用依赖注入,将 WalletRpcService 对象的创建反转给上层逻辑,在外部创建好之后,再注入到 Transaction 类中。
- 重构后的 Transaction 类中,增加 setWalletRpcService() 方法,将 WalletRpcService 对象传入。
- 在 execute() 方法中删除 new WalletRpcService(),直接使用 this.walletRpcService。
重新封装transaction 上锁
- 增加 TransactionLock 类,里面的方法lock() 和 unlock() 调用原来的分布式锁 DistributedLock 单例类。
- 然后在 Transaction 中 setTransactionLock() ,依赖注入 TransactionLock 类。
实现测试用例3
- 将创建时间设置为14天前,来测试交易过期。transaction.setCreatedTimestamp(System.currentTimestamp() - 14days)。
- 但是,如果在 Transaction 类中,并没有暴露修改 createdTimestamp 成员变量的 set 方法(也就是没有定义 setCreatedTimestamp() 函数)呢?
- 你可能会说,如果没有 createTimestamp 的 set 方法,我就重新添加一个呗!实际上,这违反了类的封装特性。
- 在 Transaction 类的设计中,createTimestamp 是在交易生成时(也就是构造函数中)自动获取的系统时间,本来就不应该人为地轻易修改。因为,我们无法控制使用者是否会调用 set 方法重设 createTimestamp,而重设 createTimestamp 并非我们的预期行为。
- 代码中包含跟“时间”有关的“未决行为”逻辑,我们一般的处理方式是将这种未决行为逻辑重新封装(见下文:重新封装未决行为逻辑)。
- 这样我们在测试类中可以重写 isExpired() 方法,随意更改返回交易是否过期。
重新封装未决行为逻辑
- 在 Transaction 类中增加 isExpired() 方法,封装交易是否过期逻辑。
- 在 execute() 方法中,可以直接调用 isExpired() 方法来判断过期问题。
测试 Transaction 类的构造函数
- 造函数中并非只包含简单赋值操作。
- 交易 id 的赋值逻辑稍微复杂,可以把 id 赋值这部分逻辑单独抽象到一个方法中 fillTransactionId()。
实战总结
- 重构之后的代码,不仅可测试性更好,而且从代码设计的角度来说,也遵从了经典的设计原则和思想。
- 代码的可测试性可以从侧面上反应代码设计是否合理。
- 在平时的开发中,我们也要多思考一下,这样编写代码,是否容易编写单元测试,这也有利于我们设计出好的代码。
其他常见的 Anti-Patterns
未决行为
- 所谓的未决行为逻辑就是,代码的输出是随机或者说不确定的,比如,跟时间、随机数有关的代码。
全局变量
- 前面我们讲过,全局变量是一种面向过程的编程风格,有种种弊端。实际上,滥用全局变量也让编写单元测试变得困难。
- 文中举例:
- RangeLimiter 表示一个 [-5, 5] 的区间
- position 初始在 0 位置
- move() 函数负责移动 position
- position 是一个静态全局变量
- 为 RangeLimiterTest 类是为其设计的单元测试,有两个测试用例:
- testMove_betweenRange() 中分别 move(1)、move(3)、move(-5)
- testMove_exceedRange() 中 move(6)
- 问题:
- 测试用例 testMove_betweenRange() 执行之后,position 的值变成了 -1
- 测试用例 testMove_exceedRange() 执行之后,position 的值变成了 5,move() 函数返回 true,assertFalse 语句判定失败
- 所以第二个测试用例运行失败
- 如果 RangeLimiter 类有暴露重设(reset)position 值的函数,我们可以在每次执行单元测试用例之前,把 position 重设为 0,这样就能解决刚刚的问题。
- 不过,每个单元测试框架执行单元测试用例的方式可能是不同的。有的是顺序执行,有的是并发执行。对于并发执行的情况,即便我们每次都把 position 重设为 0,也并不奏效。
静态方法
- 静态方法跟全局变量一样,也是一种面向过程的编程思维。
- 在代码中调用静态方法,有时候会导致代码不易测试。主要原因是静态方法也很难 mock。
- 只有在这个静态方法执行耗时太长、依赖外部资源、逻辑复杂、行为未决等情况下,我们才需要在单元测试中 mock 这个静态方法。
复杂继承
- 相比组合关系,继承关系的代码结构更加耦合、不灵活,更加不易扩展、不易维护。实际上,继承关系也更加难测试。
- 如果父类需要 mock 某个依赖对象才能进行单元测试,那所有的子类、子类的子类……在编写单元测试的时候,都要 mock 这个依赖对象。
- 对于层次很深(在继承关系类图中表现为纵向深度)、结构复杂(在继承关系类图中表现为横向广度)的继承关系,越底层的子类要 mock 的对象可能就会越多。
- 如果我们利用组合而非继承来组织类之间的关系,类之间的结构层次比较扁平,在编写单元测试的时候,只需要 mock 类所组合依赖的对象即可。
高耦合代码
- 如果一个类职责很重,需要依赖十几个外部对象才能完成工作,代码高度耦合,那我们在编写单元测试的时候,可能需要 mock 这十几个依赖的对象。