设计模式学习笔记 - 规范与重构 - 3.什么是代码的可测试性？如何写出可测试性好的代码？

前言

上一节课《2.保证重构不出错的技术手段》，介绍了单元测试相关内容。

实际上，写单元测试不难，也不需要太多技巧，相反，写出可测试的代码反倒是件非常难的事情。所以，我们今天学下代码的可测试性相关知识。主要包括下面几个问题：

1. 什么是代码的可测试性？
2. 如何写出可测试的代码？
3. 有哪些常见的不好测试的代码？

---

编写可测试代码案例实战

我准备了通过一个实战案例来讲解代码可测试性的问题。具体代码如下所示。

其中，Transaction 是经过我们抽象简化后的一个电商系统的交易类，用来记录每笔订单交易的情况。Transaction 类中的 execute() 函数负责执行转账操作，将钱从买家的钱包转到卖家的钱包中。真正的转账操作是通过调用 WalletRpcService RPC 服务来完成。此外，代码中还涉及一个分布式锁 DistributedLock 单例类，用来避免 Transaction 并发执行，导致用户的钱被重复转出。

public class Transaction {
    private String id;
    private Long buyerId;
    private Long sellerId;
    private Long productId;
    private String orderId;
    private Long createTimestamp;
    private Double amount;
    private STATUS status;
    private String walletTransactionId;

    // get() methods...


    public Transaction(String preAssignedId, Long buyerId, Long sellerId, Long productId, String orderId, Double amount) {
        if (preAssignedId != null && !preAssignedId.isEmpty()) {
            this.id = preAssignedId;
        } else {
            this.id = IdGenerator.generateTranslationId();
        }
        if (!this.id.startsWith("t_")) {
            this.id = "t_" + this.id;
        }
        this.buyerId = buyerId;
        this.sellerId = sellerId;
        this.productId = productId;
        this.orderId = orderId;
        this.status = STATUS.TO_BE_EXECUTED;
        this.createTimestamp = System.currentTimeMillis();
        this.amount = amount;
    }

    public boolean execute() throws InvalidTransactionException {
        if (buyerId == null || sellerId == null || amount < 0.0) {
            throw new InvalidTransactionException("...");
        }
        if (status == STATUS.EXECUTED) return true;
        boolean isLocked = false;
        try {
            isLocked = RedisDistributedLock.getSingletonInstance().lockTransaction(id);
            if (!isLocked) {
                return false; // 锁为成功，返回false，job兜底执行
            }
            if (status == STATUS.EXECUTED) return true;
            long executionInvokeTimestamp = System.currentTimeMillis();
            if (executionInvokeTimestamp - createTimestamp > 14) {
                this.status = STATUS.EXPIRED;
                return false;
            }
            WalletRpcService walletRpcService = new WalletRpcService();
            String wallerTransactionId = walletRpcService.moveMoney(id, buyerId, sellerId, amount);
            if (wallerTransactionId != null) {
                this.walletTransactionId = wallerTransactionId;
                this.status = STATUS.EXECUTED;
                return true;
            } else {
                this.status = STATUS.FAILED;
                return false;
            }
        } finally {
            if (isLocked) {
                RedisDistributedLock.getSingletonInstance().unlockTransaction(id);
            }
        }
    }
}

如果让你给这段代码编写单元测试，你会如何来写呢？你可以试着思考一下，然后再来看下下面的分析。

在 Transaction 类中，主要逻辑集中在 execute() 函数中，所以它是我们测试的重点对象。为了尽可能全面覆盖各种正常和异常的情况，针对这个函数，设计了下面 6 个测试案例。

1. 正常情况下，交易执行成功，回填用于对账的（交易与钱包的交易流水）用的 walletTransactionId，交易状态为 EXCUTED，函数返回 true。
2. buyerId、sellerId、amount 小于 0，函数抛出 InvalidTransactionException。
3. 交易已过期（createTimestamp 超过 14 天），交易状态设置为 EXPIRED，返回 false。
4. 交易已经执行了(status == STATUS.EXECUTED)，不再重复执行转钱逻辑，函数返回 false。
5. 钱包 WalletRpcService 转钱失败，交易状态设置为 FAILED，函数返回 false。
6. 交易正在执行着，不会被重复执行，函数直接返回 false。

测试用例设计完了，现在看起来一切似乎进展顺利。但是，事实是，当我们将测试用例落实到具体的代码时，你会发现有很多不通的地方。对于上面的测试用例，第 2 个实现起来非常简单，就不介绍了。我们重点看下其中的 1 和 3。测试用例 4、5、6 和 3 类似，留给你自己实现。

现在，我们就来看测试用例 1 的代码实现。具体代码如下：

public void textExecuted() {
    Long buyerId = 123L;
    Long sellerId = 234L;
    Long productId = 345L;
    String orderId = "346";
    Double amount = 1.0;

    Transaction transaction = new Transaction(null, buyerId, sellerId, productId, orderId, amount);
    assertTrue(transaction.execute());
}

execute() 执行依赖两个外部的服务，一个是 RedisDistributedLock，一个是 WalletRpcService。这就导致上面的单元测试代码存在以下几个问题：

• 如果需要让这个单元测试能够运行，我们需要搭建 Redis 服务和 Wallet RPC 服务。搭建和维护的成本比较高。
• 我们还需要保证伪造的 transaction 数据发送给 Wallet RPC 服务之后，能够正确返回我们期望的结果，然后 Wallet RPC 服务有可能是第三方的服务（另一个团队开发维护的），并不是我们可控的。换句话说，并不是我们想让它返回什么数据就返回什么。
• Transaction 的执行跟 Redis、RPC 服务通信，需要走网络，耗时可能会比较长，对单元测试本身的执行性能也会有影响。
• 网络的中断、超时、Redis、RPC 服务的不可用，都会影响单元测试的执行。

我们回到单元测试的定义上来看一下。单元测试主要是测试程序员自己编写的代码逻辑的正确性，并非是端到端的测试，它不需要测试所依赖的外部系统（分布式锁、Wallet RPC 服务）的逻辑正确性。所以，如果代码中依赖了外部系统或者不可控组件，比如，需要依赖数据库、网络通信、文件系统等，那我们就需要将被测试代码与外部系统解依赖，而这种解依赖的方法叫做 “mock”。所谓 “mock” 就是用一个 “假” 的服务替换真正的服务。mock 服务完全在我们的控制之下，模拟输出我们想要的数据。

如何来 mock 服务呢？
mock的方式主要有两种，手动 mock 服务和利用框架 mock。利用框架来 mock 仅仅是为了简化代码编写，每个框架的 mock 方式都不大一样。我们这里只展示手动 mock。

我们通过继承 WalletRpcService 类，并重写其中的 moveMoney() 方法来实现 mock。具体的代码如下所示。通过 mock 的方式，我们可以让 moveMoney() 返回任意我们想要的数据，完全在我们的控制范围内，并且不需要真正进行网络通信。

public class WalletRpcServiceOne extends WalletRpcService {
    @Override
    public String moveMoney(String id, Long buyerId, Long sellerId, Double amount) {
        return "123bb";
    }
}

public class WalletRpcServiceTwo extends WalletRpcService {
    @Override
    public String moveMoney(String id, Long buyerId, Long sellerId, Double amount) {
        return null;
    }
}

现在看下，如何用 WalletRpcServiceOne、WalletRpcServiceTwo 来替换代码中真正的 WalletRpcService 呢？

因为 WalletRpcService 是在 execute() 函数中通过 new 的方式创建的，我们无法动态地对其进行替换。也就是说， Transaction 类中的 execute() 方法的可测性很差，需要通过重构来让其变得更加容易测试。该如何重构这段代码呢？

public class Transaction {
    // ...
    // 添加一个成员变量
    private WalletRpcService walletRpcService;
    
    public void setWalletRpcService(WalletRpcService walletRpcService) {
        this.walletRpcService = walletRpcService;
    }
    // ...
    public boolean execute() throws InvalidTransactionException {
        // ...
        // 删除下面这行代码
        // WalletRpcService walletRpcService = new WalletRpcService();
        // ...  
    }
}

现在我们就可以在单元测试中，非常容易的将 WalletRpcService 替换成 WalletRpcServiceOne 或 WalletRpcServiceTwo 了。重构之后的代码对应的单元测试如下所示：

public void textExecuted() {
    Long buyerId = 123L;
    Long sellerId = 234L;
    Long productId = 345L;
    String orderId = "346";
    Double amount = 1.0;

    Transaction transaction = new Transaction(null, buyerId, sellerId, productId, orderId, amount);
    // 使用mock对象来替代真正的RPC服务
    transaction.setWalletRpcService(new WalletRpcServiceOne());
    assertTrue(transaction.execute());
    assertEquals(STATUS.EXECUTED, transaction.getStatus());
}

WalletRpcService 的 mock 和替换问题解决了，我们再来看下 RedisDistributedLock。它 mock 和替换相比要复杂一些，主要是因为 RedisDistributedLock 是一个单例类。单例相当于一个全局变量，我们无法 mock （无法继承和重写方法），也无法通过依赖注入的方式来替换。

如果 RedisDistributedLock 是我们自己维护的，可以自由修改、重构，那我们可以将其改为非单例的模式，或者定义一个接口，比如 IDistributedLock，让 RedisDistributedLock 实现这个接口。这样我们就可以向前面 WalletRpcService 的替换方式那样，替换 RedisDistributedLock 为 MockRedisDistributedLock 了。但是如果 RedisDistributedLock 不是我们维护的，我们无权去修改这部分代码，这个时候该怎么办呢？

我们可以对 Transaction 上锁这部分逻辑重新封装一下。代码如下所示：

public class TransactionLock {
    public boolean lock(String id) {
        return RedisDistributedLock.getSingletonInstance().lockTransaction(id);
    }

    public void unlock(String id) {
        RedisDistributedLock.getSingletonInstance().unlockTransaction(id);
    }
}

public class Transaction {
    // ...
    private TransactionLock lock;
    
    public void setTransactionLock(TransactionLock lock) {
        this.lock = lock;
    }
	// ...
    public boolean execute() throws InvalidTransactionException {
        // ...
        try {
            isLocked = lock.lock(id);
            // ...
        } finally {
            if (isLocked) {
                lock.unlock(id);
            }
        }
    }
}

重构过后的代码，我们的单元测试代码修改为下面的样子。这样，我们就能在单元测试中隔离真正的 RedisDistributedLock 分布式锁这部分逻辑了。

public void textExecuted() {
    Long buyerId = 123L;
    Long sellerId = 234L;
    Long productId = 345L;
    String orderId = "346";
    Double amount = 1.0;
    
    TransactionLock mockLock = new TransactionLock() {
        @Override
        public boolean lock(String id) {
            return true;
        }
        @Override
        public void unlock(String id) {}
    };

    Transaction transaction = new Transaction(null, buyerId, sellerId, productId, orderId, amount);
    // 使用mock对象来替代真正的RPC服务
    transaction.setWalletRpcService(new WalletRpcServiceOne());
    transaction.setTransactionLock(mockLock);
    assertTrue(transaction.execute());
    assertEquals(STATUS.EXECUTED, transaction.getStatus());
}

至此，测试用例 1 就算写好了。我们通过依赖注入和 mock ，让单元测试代码不依赖任何不可控的外部服务。你可以照着这个思路，自己写一下测试用例 4、5、6。

我们再来看下测试用例 3：交易已过期（createTimestamp 超过 14 天），交易状态设置为 EXPIRED，返回 false。针对这个单元测试用例，我们还是先把代码写出来，然后再来分析。

public void textExecuted_with_TransactionIsExpired() {
    Long buyerId = 123L;
    Long sellerId = 234L;
    Long productId = 345L;
    String orderId = "346";
    Double amount = 1.0;

    Transaction transaction = new Transaction(null, buyerId, sellerId, productId, orderId, amount);
    // 使用mock对象来替代真正的RPC服务
    transaction.setCreatedTimestamp(System.currentTimeMillis() - 14days);
    boolean acutalResult = transaction.execute();
    assertFalse(acutalResult);
    assertEquals(STATUS.EXPIRED, transaction.getStatus());
}

上面的代码看似没有任何问题。我们将 transaction 的创建时间 createTimestamp 设置为 14 天前，也就是说，当测试代码运行的时候，transaction 一定是处于过期状态。但是如果在 Transaction 类中，并没有暴露修改 createTimestamp 成员的 set 方法（也就是没有定义 setCreatedTimestamp()）呢？

可能你会说，没有我就自己重新添加一个呗。实际上，这违反了类的封装特性。在 Transaction 类的设计中，createTimestamp 是在交易生成时（也就是构造函数中）自动获取系统时间，本来就不应该人为地轻易修改，所以暴露 createTimestamp 的 set 方法，虽然带来了灵活性，但也带来了不可控性。因为，我们无法控制调用者是否会调用 set 方法重写设置 createTimestamp ，而重设 createTimestamp 并非我们的预期行为。

那如果没有针对 createTimestamp 的 set 方法，那测试用例 3 又该如何实现呢？实际上，这是一类比较常见的问题，就是代码中包含跟 “时间” 有关的 “未决行为” 逻辑。

所谓的未决行为逻辑就是，代码的输出结果是随机或者说不确定的，比如，跟时间、随机数有关的代码。

我们一般的处理方式是将这种未决行为逻辑重新封装。针对 Transaction 类，我们只需要将交易是否过期的逻辑，封装到 isExpired() 函数中即可，具体代码如下所示：

public class Transaction {
    // ...
    public boolean isExpired() {
        long executionInvokedTimestamp = System.currentTimeMillis();
        return executionInvokedTimestamp - createTimestamp > 14days;
    }
	// ...
    public boolean execute() throws InvalidTransactionException {
        // ...
            if (isExpired()) {
                this.status = STATUS.EXPIRED;
                return false;
            }
        // ....
    }
}

针对重构之后的代码，测试用例 3 的代码如下所示：

public void textExecuted_with_TransactionIsExpired() {
    Long buyerId = 123L;
    Long sellerId = 234L;
    Long productId = 345L;
    String orderId = "346";
    Double amount = 1.0;

    Transaction transaction = new Transaction(null, buyerId, sellerId, productId, orderId, amount) {
        @Override
        public boolean isExpired() {
            return true;
        }
    };
    boolean acutalResult = transaction.execute();
    assertFalse(acutalResult);
    assertEquals(STATUS.EXPIRED, transaction.getStatus());
}

通过重构， Transaction 代码的可测试提高了。之前罗列的所有测试用例，现在我们都顺利实现了。不过， Transaction 类的构造函数的设计还有点不妥。为了方便你查看，我把构造函数的代码重新贴下：

public Transaction(String preAssignedId, Long buyerId, Long sellerId, Long productId, String orderId, Double amount) {
    if (preAssignedId != null && !preAssignedId.isEmpty()) {
        this.id = preAssignedId;
    } else {
        this.id = IdGenerator.generateTranslationId();
    }
    if (!this.id.startsWith("t_")) {
        this.id = "t_" + this.id;
    }
    this.buyerId = buyerId;
    this.sellerId = sellerId;
    this.productId = productId;
    this.orderId = orderId;
    this.status = STATUS.TO_BE_EXECUTED;
    this.createTimestamp = System.currentTimeMillis();
    this.amount = amount;
}

我们发现构造函数并非只包含简单的赋值操作。交易 id 的逻辑稍微有点复杂。我们最好也要测试一下，以保证这部分逻辑的正确性。为了方便测试，我们可以把 id 复制这部分逻辑单独抽象到一个函数中，具体的代码实现如下所示：

public class Transaction {
    // ...

    public Transaction(String preAssignedId, Long buyerId, Long sellerId, Long productId, String orderId, Double amount) {
    	// ...
        fillTransactionId(preAssignedId);
        // ...
    }
    
    protected void fillTransactionId(String preAssignedId) {
        if (preAssignedId != null && !preAssignedId.isEmpty()) {
            this.id = preAssignedId;
        } else {
            this.id = IdGenerator.generateTranslationId();
        }
        if (!this.id.startsWith("t_")) {
            this.id = "t_" + this.id;
        }
    }
    // ...
}

到此为止，我们一步一步将 Transaction 从不可测试代码重构成了测试性良好的代码。不过，你可能还会有疑问， Transaction 中 isExpired() 函数就不用测试了吗？对于 isExpired() 函数，逻辑非常简单，肉眼就能判定是否有 bug，是可以不用写单元测试的。

实际上，可测试性差的代码，本身代码设计得也不够好，很多地方都没有遵守我们之前讲过的设计原则和思想，比如 “基于接口而非实现编程” 思想、依赖反转原则等。重构之后的代码，不仅可测试性更好，从代码设计的角度来说，也遵从了经典的设计原则和思想。这也印证了我们之前说过的，代码的可测试性可以从侧面上反应代码设计是否合理。除此之外，在平时开发中，我们也要多思考一下，这样编写代码，是否容易编写单元测试，这也有利于我们设计出好的代码。

其他场景的 Anti-Patterns

刚刚通过一个实战案例，讲解了如何利用依赖注入来提高代码的可测试性，以及编写单元测试中最复杂的一部分：如果通过 mock、二次封装方式解依赖外部服务。现在，我们总结下，有哪些典型的、常见的测试性不好的代码，也就是我们常说的 Anti-Patterns。

1.未决行为

所谓的未决行为逻辑就是，代码的输出是随机或者说不确定的，比如，跟时间、随机数有关的代码。对于这一点，在刚刚的实战案例中我们已经讲到，你可以利用刚才讲到的方法，试着重构以下下面的代码，并且为它编写单元测试。

public class Demo {
    public long calDays(Date dueTime) {
        long currentTimestamp = System.currentTimeMillis();
        if (dueTime.getTime() >= currentTimestamp) {
            return 0;
        }
        long delayTime = currentTimestamp - dueTime.getTime();
        long delayDays = delayTime / 86400;
        return delayDays;
    }
}

2.全局变量

前面讲过（面向对象 - 4.什么代码看似面向对象，实际是面向过程的），全局变量是一种面向过程的编程过程。实际上，滥用全局变量也让编写单元测试变得困难。我举个例子来解释下。

public class RangeLimiter {
    private static AtomicInteger position = new AtomicInteger(0);
    private static final int MAX_LIMIT = 5;
    private static final int MIN_LIMIT = -5;

    public boolean move(int delta) {
        int currentPos = position.addAndGet(delta);
        boolean betweenRange = (currentPos <= MAX_LIMIT) && (currentPos >= MIN_LIMIT);
        return betweenRange;
    }
}

public class RangeLimiterTest {
    public void testMove_betweenRange() {
        RangeLimiter rangeLimiter = new RangeLimiter();
        assertTrue(rangeLimiter.move(1));
        assertTrue(rangeLimiter.move(3));
        assertTrue(rangeLimiter.move(-5));
    }

    public void testMove_exceedRange() {
        RangeLimiter rangeLimiter = new RangeLimiter();
        assertFalse(rangeLimiter.move(6));
    }
}

上面的单元测试可能会运行失败。假设单元测试框架顺序依次执行 testMove_betweenRange() 和 testMove_exceedRange() 两个测试案例。在第一个测试案例执行完成之后，position 的值变成了 -1; 再执行第二个测试用例的时候，position 变成了 5，move() 返回 true。assertFalse 语句判定失败。所以，第二个测试用例运行失败。

当然，如果 RangeLimiter 类有暴露重设（resst） position 值的函数，我们可以在每次执行单元测试前，把 position 重设为 0，这样就能解决刚刚的问题。

不过，每个单元测试框架执行单元测试用例的方式可能是不同的。有的是顺序执行，有的是并发执行。对于并发执行的情况，即便我们每次都把 position 重设为 0，也并不奏效。如果两个测试用例并发执行，第 16、17、18、23 这四行代码可能会交叉执行，影响到 move() 函数的执行结果。

3.静态方法

前面讲过（面向对象 - 4.什么代码看似面向对象，实际是面向过程的），静态方法跟全局变量一样，也是一种面向过程的编程过程。

主要原因是静态方法也很难 mock。但是，这个要分情况来看。只有在这个静态执行耗时太长、依赖外部资源、逻辑复杂、行为未决等情况下，我们才需要在单元测试中 mock 这个静态方法。此外，如果只是类似 Math.abs() 这样的静态方法，并不会影响代码的可测试性，因为本身并不需要 mock。

4.复杂继承

前面讲过（面向对象 - 7.为什么要多用组合少用继承？如何决定该用组合还是继承？），相比组合关系，继承关系的代码结构更加耦合、不灵活，更加不易扩展、不易维护。实际上，继承关系也更加难测试。这也印证了代码的可测试性跟代码质量的相关性。

如果父类需要 mock 某个依赖对象才能进行单元测试，那所有的子类、子类的子类、… 在编写单元测试的时候，都要 mock 这个依赖对象。对于层次很深（在继承关系图中表现为纵向深度）、结构复杂（在继承关系图中表现为横向扩展）的继承关系，越底层的子类要 mock 的对象可能会越多，这样就会导致，底层子类在编写单元测试的时候，要一个一个 mock 很多对象，而且还需要查看父类代码，去了解如何 mock 这些依赖对象。

如果我们利用组合而非继承关系来组织类之间的关系，类之间的结构层次比较扁平，在编写单元测试的时候，只需要 mock 类所组合依赖的对象即可。

5.高耦合代码

如果一个类职责很重，需要依赖十几个外部对象才能完成工作，代码高度耦合，那我们在编写单元测试的时候，可能需要 mock 这十几个依赖的对象。不管是从代码设计的角度来说，还是从编写单元测试的角度来说，这都是不合理的。

总结

1.什么是代码的可测试性?

粗略地讲，所谓代码的可测试性，就是针对代码编写单元测试的难易程度。对于一段代码，如果很难为其编写单元测试，或者单元测试写起来很费劲，需要依靠单元测试框架中很高级的特性，那往往就意味着代码设计得不够合理，代码的可测试性不好。

2.编写可测试性代码的最有效手段？

依赖注入是编写可测试代码的最有效手段。通过依赖注入，我们在编写单元测试的时候，可以通过 mock 的方法解依赖外部服务，这也是我们在编写单元测试的过程中最有技术挑战的地方。

3.常见的 Anti-Patterns

常见的测试不友好的代码有下面这 5 种：

• 代码中包含未决行为逻辑
• 滥用全局变量
• 滥用静态方法
• 使用复杂的继承关系
• 高度耦合的代码