【设计模式之美】重构一：重构定义、单元测试保证重构正确性

roman_日积跬步-终至千里2024-01-13 16:35

文章目录

  • [一. 重构概述](#一. 重构概述)
    • [1. 为什么要重构（why）？](#1. 为什么要重构（why）？)
    • [2. 到底重构什么（what）？](#2. 到底重构什么（what）？)
    • [3. 什么时候重构（when）？](#3. 什么时候重构（when）？)
    • [4. 该如何重构（how）？](#4. 该如何重构（how）？)
    • [5. 如何保证重构不出错？](#5. 如何保证重构不出错？)
  • [二. 单元测试方法论](#二. 单元测试方法论)
    • [1. 什么是单元测试？](#1. 什么是单元测试？)
    • [2. 为什么要写单元测试？](#2. 为什么要写单元测试？)
    • [3. 如何编写单元测试？](#3. 如何编写单元测试？)

一. 重构概述

重构的要求：

一方面，重构代码对一个工程师能力的要求，要比单纯写代码高得多。重构需要你能洞察出代码存在的坏味道或者设计上的不足，并且能合理、熟练地利用设计思想、原则、模式、编程规范等理论知识解决这些问题。

另一方面，很多工程师对为什么要重构、到底重构什么、什么时候重构、又该如何重构等相关问题理解不深，对重构没有系统性、全局性的认识，面对一堆烂代码，没有重构技巧的指导，只能想到哪改到哪，并不能全面地改善代码质量。

1. 为什么要重构（why）？

重构定义：

这个定义中有一个值得强调的点："重构不改变外部的可见行为"。

为什么要进行代码重构？

  • 首先，重构是时刻保证代码质量的一个极其有效的手段。

  • 其次，优秀的代码或架构不是一开始就能完全设计好的，就像优秀的公司和产品也都是迭代出来的。我们无法 100% 遇见未来的需求，也没有足够的精力、时间、资源为遥远的未来买单，所以，随着系统的演进，重构代码也是不可避免的。

  • 最后，重构是避免过度设计的有效手段。在我们维护代码的过程中，真正遇到问题的时候，再对代码进行重构，能有效避免前期投入太多时间做过度的设计，做到有的放矢。

2. 到底重构什么（what）？

根据重构的规模，我们可以笼统地分为大规模高层次重构（以下简称为"大型重构"）和小规模低层次的重构（以下简称为"小型重构"）。

大型重构

大型重构指的是对顶层代码设计的重构，包括：系统、模块、代码结构、类与类之间的关系等的重构，重构的手段有：分层、模块化、解耦、抽象可复用组件等等。

这类重构的工具就是我们学习过的那些设计思想、原则和模式。这类重构涉及的代码改动会比较多，影响面会比较大，所以难度也较大，耗时会比较长，引入 bug 的风险也会相对比较大。

小型重构

小型重构指的是对代码细节的重构，主要是针对类、函数、变量等代码级别的重构，比如规范命名、规范注释、消除超大类或函数、提取重复代码等等。

小型重构更多的是利用我们能后面要讲到的编码规范。这类重构要修改的地方比较集中，比较简单，可操作性较强，耗时会比较短，引入 bug 的风险相对来说也会比较小。你只需要熟练掌握各种编码规范，就可以做到得心应手。

3. 什么时候重构（when）？

提倡的重构策略是持续重构。

就像把单元测试、Code Review 作为开发的一部分，我们如果能把持续重构也作为开发的一部分，成为一种开发习惯，对项目、对自己都会很有好处。

4. 该如何重构（how）？

每个阶段，要控制好重构影响到的代码范围，考虑好如何兼容老的代码逻辑，必要的时候还需要写一些兼容过渡代码。只有这样，我们才能让每一阶段的重构都不至于耗时太长（最好一天就能完成），不至于与新的功能开发相冲突。

5. 如何保证重构不出错？

最可落地执行、最有效的保证重构不出错的手段应该就是单元测试（Unit Testing）了。当重构完成之后，如果新的代码仍然能通过单元测试，那就说明代码原有逻辑的正确性未被破坏，原有的外部可见行为未变，符合我们对重构的定义。

二. 单元测试方法论

1. 什么是单元测试？

单元测试相对于集成测试（Integration Testing）来说，测试的粒度更小一些。

  • 集成测试的测试对象是整个系统或者某个功能模块，比如测试用户注册、登录功能是否正常，是一种端到端（end to end）的测试。
  • 单元测试的测试对象是类或者函数，用来测试一个类和函数是否都按照预期的逻辑执行。这是代码层级的测试。

写单元测试本身不需要什么高深技术。它更多的是考验程序员思维的缜密程度，看能否设计出覆盖各种正常及异常情况的测试用例，来保证代码在任何预期或非预期的情况下都能正确运行。

举例

java 复制代码 
public class Text {
  private String content;

  public Text(String content) {
    this.content = content;
  }

  /**
   * 将字符串转化成数字，忽略字符串中的首尾空格；
   * 如果字符串中包含除首尾空格之外的非数字字符，则返回null。
   */
  public Integer toNumber() {
    if (content == null || content.isEmpty()) {
      return null;
    }
    //...省略代码实现...
    return null;
  }
}

我们需要设计下面这样几个测试用例。

当我们设计好测试用例之后，剩下的就是将其翻译成代码了。

c 复制代码 
public class Assert {
  public static void assertEquals(Integer expectedValue, Integer actualValue) {
    if (actualValue != expectedValue) {
      String message = String.format(
              "Test failed, expected: %d, actual: %d.", expectedValue, actualValue);
      System.out.println(message);
    } else {
      System.out.println("Test succeeded.");
    }
  }

  public static boolean assertNull(Integer actualValue) {
    boolean isNull = actualValue == null;
    if (isNull) {
      System.out.println("Test succeeded.");
    } else {
      System.out.println("Test failed, the value is not null:" + actualValue);
    }
    return isNull;
  }
}

public class TestCaseRunner {
  public static void main(String[] args) {
    System.out.println("Run testToNumber()");
    new TextTest().testToNumber();

    System.out.println("Run testToNumber_nullorEmpty()");
    new TextTest().testToNumber_nullorEmpty();

    System.out.println("Run testToNumber_containsLeadingAndTrailingSpaces()");
    new TextTest().testToNumber_containsLeadingAndTrailingSpaces();

    System.out.println("Run testToNumber_containsMultiLeadingAndTrailingSpaces()");
    new TextTest().testToNumber_containsMultiLeadingAndTrailingSpaces();

    System.out.println("Run testToNumber_containsInvalidCharaters()");
    new TextTest().testToNumber_containsInvalidCharaters();
  }
}

public class TextTest {
  public void testToNumber() {
    Text text = new Text("123");
    Assert.assertEquals(123, text.toNumber());
  }

  public void testToNumber_nullorEmpty() {
    Text text1 = new Text(null);
    Assert.assertNull(text1.toNumber());

    Text text2 = new Text("");
    Assert.assertNull(text2.toNumber());
  }

  public void testToNumber_containsLeadingAndTrailingSpaces() {
    Text text1 = new Text(" 123");
    Assert.assertEquals(123, text1.toNumber());

    Text text2 = new Text("123 ");
    Assert.assertEquals(123, text2.toNumber());

    Text text3 = new Text(" 123 ");
    Assert.assertEquals(123, text3.toNumber());
  }

  public void testToNumber_containsMultiLeadingAndTrailingSpaces() {
    Text text1 = new Text("  123");
    Assert.assertEquals(123, text1.toNumber());

    Text text2 = new Text("123  ");
    Assert.assertEquals(123, text2.toNumber());

    Text text3 = new Text("  123  ");
    Assert.assertEquals(123, text3.toNumber());
  }

  public void testToNumber_containsInvalidCharaters() {
    Text text1 = new Text("123a4");
    Assert.assertNull(text1.toNumber());

    Text text2 = new Text("123 4");
    Assert.assertNull(text2.toNumber());
  }
}

2. 为什么要写单元测试？

2.1.单元测试能有效地帮你发现代码中的 bug

在离开 Google 之后，尽管我就职的很多公司，其开发模式都是"快、糙、猛"，对单元测试根本没有要求，但我还是坚持为自己提交的每一份代码，都编写完善的单元测试。得益于此，我写的代码几乎是 bug free 的。这也节省了我很多 fix 低级 bug 的时间，能够有时间去做其他更有意义的事情，我也因此在工作上赢得了很多人的认可。可以这么说，坚持写单元测试是保证我的代码质量的一个"杀手锏"，也是帮助我拉开与其他人差距的一个"小秘密"。--- 王争

2.2. 写单元测试能帮你发现代码设计上的问题

前面我们提到，代码的可测试性是评判代码质量的一个重要标准 。对于一段代码，如果很难为其编写单元测试，或者单元测试写起来很吃力，需要依靠单元测试框架里很高级的特性才能完成，那往往就意味着代码设计得不够合理，比如，没有使用依赖注入、大量使用静态函数、全局变量、代码高度耦合等。

2.3. 单元测试是对集成测试的有力补充

  • 程序运行的 bug 往往出现在一些边界条件、异常情况下，比如，除数未判空、网络超时。而大部分异常情况都比较难在测试环境中模拟。而单元测试可以利用mock 的方式，控制 mock 的对象返回我们需要模拟的异常，来测试代码在这些异常情况的表现。
  • 除此之外，对于一些复杂系统来说，集成测试也无法覆盖得很全面。复杂系统往往有很多模块。每个模块都有各种输入、输出、异常情况，组合起来，整个系统就有无数测试场景需要模拟，无数的测试用例需要设计，再强大的测试团队也无法穷举完备。

2.4. 写单元测试的过程本身就是代码重构的过程

设计和实现代码的时候，我们很难把所有的问题都想清楚。而编写单元测试就相当于对代码的一次自我 Code Review，在这个过程中，我们可以发现一些设计上的问题（比如代码设计的不可测试）以及代码编写方面的问题（比如一些边界条件处理不当）等，然后针对性的进行重构。

2.5. 阅读单元测试能帮助你快速熟悉代码

在没有文档和注释的情况下，单元测试就起了替代性作用。单元测试用例实际上就是用户用例，反映了代码的功能和如何使用。借助单元测试，我们不需要深入的阅读代码，便能知道代码实现了什么功能，有哪些特殊情况需要考虑，有哪些边界条件需要处理。

2.6. 单元测试是 TDD 可落地执行的改进方案

单元测试是对 TDD （测试驱动开发）的一种改进方案，先写代码，紧接着写单元测试，最后根据单元测试反馈出来问题，再回过头去重构代码。这个开发流程更加容易被接受，更加容易落地执行，而且又兼顾了 TDD 的优点。

3. 如何编写单元测试？

写单元测试就是针对代码设计覆盖各种输入、异常、边界条件的测试用例，并将这些测试用例翻译成代码的过程。

利用单元测试框架，来简化测试代码的编写。

针对 toNumber() 函数的测试用例，我们利用 Junit 单元测试框架重新实现。

java 复制代码 
import org.junit.Assert;
import org.junit.Test;

public class TextTest {
  @Test
  public void testToNumber() {
    Text text = new Text("123");
    Assert.assertEquals(new Integer(123), text.toNumber());
  }

  @Test
  public void testToNumber_nullorEmpty() {
    Text text1 = new Text(null);
    Assert.assertNull(text1.toNumber());

    Text text2 = new Text("");
    Assert.assertNull(text2.toNumber());
  }

  @Test
  public void testToNumber_containsLeadingAndTrailingSpaces() {
    Text text1 = new Text(" 123");
    Assert.assertEquals(new Integer(123), text1.toNumber());

    Text text2 = new Text("123 ");
    Assert.assertEquals(new Integer(123), text2.toNumber());

    Text text3 = new Text(" 123 ");
    Assert.assertEquals(new Integer(123), text3.toNumber());
  }

  @Test
  public void testToNumber_containsMultiLeadingAndTrailingSpaces() {
    Text text1 = new Text("  123");
    Assert.assertEquals(new Integer(123), text1.toNumber());

    Text text2 = new Text("123  ");
    Assert.assertEquals(new Integer(123), text2.toNumber());

    Text text3 = new Text("  123  ");
    Assert.assertEquals(new Integer(123), text3.toNumber());
  }

  @Test
  public void testToNumber_containsInvalidCharaters() {
    Text text1 = new Text("123a4");
    Assert.assertNull(text1.toNumber());

    Text text2 = new Text("123 4");
    Assert.assertNull(text2.toNumber());
  }
}

关于如何编写单元测试，具体包括以下几点。

  1. 写单元测试真的是件很耗时的事情吗？ 尽管单元测试的代码量可能是被测代码本身的 1～2 倍，写的过程很繁琐，但并不是很耗时。毕竟我们不需要考虑太多代码设计上的问题，测试代码实现起来也比较简单。不同测试用例之间的代码差别可能并不是很大，简单
    copy-paste 改改就行。
  2. 对单元测试的代码质量有什么要求吗？ 单元测试毕竟不会在产线上运行，而且每个类的测试代码也比较独立，基本不互相依赖。所以，相对于被测代码，我们对单元测试代码的质量可以放低一些要求。命名稍微有些不规范，代码稍微有些重复，也都是没有问题的。
  3. 单元测试只要覆盖率高就够了吗？ 单元测试覆盖率是比较容易量化的指标，常常作为单元测试写得好坏的评判标准。有很多现成的工具专门用来做覆盖率统计，比如，JaCoCo、Cobertura、Emma、Clover。覆盖率的计算方式有很多种，比较简单的是语句覆盖，稍微高级点的有：条件覆盖、判定覆盖、路径覆盖。
  4. 写单元测试需要了解代码的实现逻辑吗？
    单元测试只关心被测函数实现了什么功能 。我们切不可为了追求覆盖率，逐行阅读代码，然后针对实现逻辑编写单元测试。否则，一旦对代码进行重构，在代码的外部行为不变的情况下，对代码的实现逻辑进行了修改，那原本的单元测试都会运行失败，也就起不到为重构保驾护航的作用了，也违背了我们写单元测试的初衷。
  5. 如何选择单元测试框架？
    写单元测试本身不需要太复杂的技术，大部分单元测试框架都能满足。在公司内部，起码团队内部需要统一单元测试框架。

单元测试质量标准

不管覆盖率的计算方式如何高级，将覆盖率作为衡量单元测试质量的唯一标准是不合理的。实际上，更重要的是要看测试用例是否覆盖了所有可能的情况，特别是一些 corner case。

如下代码，只需要一个测试用例就可以做到 100% 覆盖率，比如 cal(10.0, 2.0)，但并不代表测试足够全面了，还需要考虑当除数等于０的情况下，代码执行是否符合预期。

java 复制代码 
public double cal(double a, double b) {
  if (b != 0) {
    return a / b;
  }
}

从过往的经验上来讲，一个项目的单元测试覆盖率在 60～70% 即可上线。如果项目对代码质量要求比较高，可以适当提高单元测试覆盖率的要求。

《设计模式之美》-- 王争

相关推荐
微三云 - 廖会灵 (私域系统开发)2 天前
企业大模型应用工程化思考：跳出 Demo 陷阱，构建「业务‑资产‑Agent」三层落地架构
人工智能·矩阵·重构
Zane19942 天前
一个 new 就能创建对象，为什么还要拆出单例、工厂、建造者、原型四种模式？
设计模式
慧都小项2 天前
Python 跨文件重构怎么验证？PyCharm 用法查找、重构预览与测试流程
python·重构·pycharm·单元测试
江畔柳前堤3 天前
字节跳动·大模型应用知识手册
前端·人工智能·深度学习·opencv·目标检测·重构·transformer
怕浪猫3 天前
一行命令复刻爆款视频，我把 Hypit 从安装跑到了出片
人工智能·设计模式·程序员
Zane19943 天前
函数式编程里的函数，其实不是你天天写的那个函数——三大编程范式的边界在哪
设计模式
Zane19944 天前
策略模式现在该不该上？一次讲清楚过度设计和设计不足怎么找平衡
设计模式
她说..4 天前
常见设计模式-模板方法模式
java·spring·设计模式·springboot
xiaofeiyang1505 天前
第六章 · 桥接 — 三支毛笔，画出九种颜色
设计模式
微三云 - 廖会灵 (私域系统开发)5 天前
私域电商多端商城系统架构实践：小程序 / APP / H5 一套后端如何落地
矩阵·重构·零售
热门推荐
01国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）02GitHub 镜像站点03如何新建文件夹？ 电脑新建文件夹的4种方法04Telegram APK 下载安装完整指南 — 2026年最新05历年考研数学一、数学二、数学三真题试卷及答案PDF06蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08人工智能（AI）发展史：详细里程碑092026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？102026 爱知・名古屋亚运会怎么看？直播平台+赛程安排分享