共计 5453 个字符，预计需要花费 14 分钟才能阅读完成。

如果代码中包含以下代码

或者上线后进行这种活动

那么这种编程方式就是祈祷式编程。

用流程图表示基本就是这个样子。

祈祷式编程有什么危害呢？

累，每次写完代码还需要再祈祷
不受控，代码运行结果主要看运气，大仙忙的时候可能保佑不了

解决这个问题有好多种方法，单元测试是其中之一。

单元测试是由开发人员编写的，用于对软件基本单元进行测试的可执行的程序。
单元（unit）是一个应用程序中最小的课测试部分。（比如一个函数，一个类

google 把测试分成小型测试、中型测试和大型测试。单元测试基本和小型测试的作用类似，但是通常也会使用 mock 或者 stub 的方式模拟外部服务。

理想情况下，单元测试应该是相互独立、可自动化运行的。

目的： 通常用单元测试来验证代码逻辑是否符合预期。完整可靠的单元测试是代码的 安全网，可以在代码修改或重构时验证业务逻辑是否正确，提前发现代码错误，减少调试时间。设计良好的单元测试某些情况下可以比文档更能反应出代码的功能和作用。

单元测试这么多优点为什么有人不喜欢写单元测试呢？

单元测试太费时间了，对于编写单元测试不熟练的新手来说，编写单元测试可能比写代码的还费时间
单元测试运行时间太长（这通常是单元测试设计不合理或者代码可测试性较差造成的
祖传代码，看都看不懂怎么写单元测试（这个确实优点棘手。。可以考虑先给新代码加单元测试
不会写单元测试

这篇文章主要关注第四个问题，如何写单元测试。

首先看一下单元测试的结构，一个完整的单元测试主要包括Arrange-Act-Assert（3A） 三部分。

Arrange– 准备数据
Act– 运行代码
Assert– 判断结果是否符合预期

比如我们要给下面这段代码（golang）加单元测试：


func Add(x, y int) int {return x + y}

单元测试代码如下：

import "testing"

func TestAdd(t *testing.T) {
    // arrange 准备数据
    x, y := 1, 2
    // act   运行
    got := Add(x, y)
    //assert  断言
    if got != 3 {t.Errorf("Add() = %v, want %v", got, 3)
    }
}

什么样的单元测试才是好的单元测试呢？

先看一个例子：

package ut

import (
    "fmt"
    "strconv"
    "strings"
)

func isNumber(num string) (int, error) {num = strings.TrimSpace(num)
    n, err := strconv.Atoi(num)
    return n, err
}

func multiply(x string, y int) string {
    // 如果 x 去除前后的空格后是数字，返回 数字的乘积
    //     比如 x="2" y=3 return "6"
    // 如果 x 去除前后的空格后不是数字，则返回字符串的 x 的 y 倍 
    //     比如 x="a" y=2 return "aa"
    num, err := isNumber(x)
    if err == nil {return fmt.Sprintf("%d", num*y)
    }
    result := ""
    for i := 0; i < y; i++ {result = fmt.Sprintf("%s%s", result, x)
    }
    return result
}

测试代码可能是这个样子。


// 测试方法的名字不直观，并不能看出具体要测试什么
func Test_multiply(t *testing.T) {
    type args struct {
        x string
        y int
    }
    // 一个测试方法中有太多的测试用例
    tests := []struct {
        name string
        args args
        want string
    }{
        {
            "return nil",
            args{
                "",
                2,
            },
            "",
        },
        {
            "return 2",
            args{
                "1",
                2,
            },
            "2",
        },
        {// 测试数据有点奇葩，不直观
            "return aaa",
            args{
                "aaaaaaaaaa",
                6,
            },
            "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
        },
    }
    for _, tt := range tests {t.Run(tt.name, func(t *testing.T) {if got := multiply(tt.args.x, tt.args.y); got != tt.want {
               // 数据错误的时候有明确标明测试数据，期望结果和实际结果，这一点还是有用的
                t.Errorf("multiply() = %v, want %v", got, tt.want)
            }
        })
    }
}

这个单元测试代码有什么问题呢？

代码比较长（这里只列出来了三个用例，实际上并没有完整覆盖全部结果）
测试方法如果出错了并不容易定位位置(三个测试数据都在一个方法，任何一个错误都会指向到同一个位置
有个测试的数据比较长，不太能直观判断测试数据是否正确
输入值并不完整，比如包含空格的数字字符串 ” 1″、” 1 “、“1 “ 并没有测试。

结合上面我们对 单元测试目的 的描述，一个好的单元测试应该满足以下几个条件：

单元测试越简单越好，一个单元测试只做一件事
对错误易于追踪，如果测试失败，错误提示应该容易帮我我们定位问题
测试函数的命名符合特定的规则 Test_{被测方法}_{输入}_{期望输出}
有用的失败消息
输入简单且能够完整运用代码的输入(包含边界值、特殊情况

比如，上边的单元测试我们改成这样：

// 测试特殊值“空字符串”func Test_multiply_empty_returnEmpty(t *testing.T) {
    // 用例简单，只包含输入、执行和判断 
    x, y, want := "", 1,""
    got := multiply(x, y)
    if got != want {
       // 有效的失败消息
        t.Errorf("multiply() = %v, want %v", got, want)
    }
}

// 测试包含空格的数字 边界值
func Test_multiply_numberWithSpace_returnNumber(t *testing.T) {
    x, y, want := "2", 3, "6"
    got := multiply(x, y)
    if got != want {t.Errorf("multiply() = %v, want %v", got, want)
    }
}
// 测试正常数据
func Test_multiply_number_returnNumber(t *testing.T) {
    x, y, want := "2", 3, "6"
    got := multiply(x, y)
    if got != want {t.Errorf("multiply() = %v, want %v", got, want)
    }
}
// 测试非数字字符 
func Test_multiply_String_returnString(t *testing.T) {
    // 输入简单的字符串就可以测试，没必要用太奇怪或者太长或者太大的数据数据
    x, y, want := "a", 3, "aaa"
    got := multiply(x, y)
    if got != want {t.Errorf("multiply() = %v, want %v", got, want)
    }
}
// 测试空格 边界值
func Test_multiply_space_returnSpace(t *testing.T) {
    x, y, want := "", 3,"   "
    got := multiply(x, y)
    if got != want {t.Errorf("multiply() = %v, want %v", got, want)
    }
}

当然这个数据也并不完整，还可以再加入：

包含空格的非数字字符
数字右侧包含空格的字符串
数字两侧都有空格的字符串

既然好的单元测试需要能完整的测试代码，那么有什么方法可以保证单元测试可以完整覆盖被测代码呢？

基于代码路径进行分析编写单元测试是一个方法。

设计测试路径时可以使用流程图的方式来分析，拿上边 multiply 的例子进行分析，这段代码的路径如下：

当然，每个路径的测试数据并不是只有一种，比如 x 为前后包含空格的数字字符串 这个路径中就包含三种情况：

左边有空格
右边有空格
两边都有空格

合理的设计测试数据非常重要，测试除了符合上边说的要简单直观以外还要着重考虑边界值。

设计测试数据通常是把可能的输入数据分成多个子集，然后从每个子集中选取具有代表性的数据作为测试用例。
比如一段代码的作用是计算个税，我们就应该按照个税不同的等级来设计测试数据，比如：

年收入 0 -36000 部分
年收入 36000-144000 部分
年收入 144000-300000 部分
年收入 300000-420000 部分
…

然后在这个子集的基础上在针对边界值做一些检查，比如 36000、144000 等。

通常情况下，如果私有方法在公有方法中有被调用，通过测试公有方法就已经可以间接测试到私有方法。

也有些私有方法写的不合理，比如私有方法没有被使用或者私有方法的功能和类的相关性不大，这个时候就建议把私有方法单独提取成新的函数或者类来测试。

当然现实世界中的代码并不会这么简单，通常都会包含外部请求或者对于其它类的调用。
在编写单元测试时，对于外部依赖我们通常使用 Mock 和 Stub 的方式来模拟外部依赖。

Mock 和 Stub 的区别：

Mock 是在测试代码中创建一个模拟对象，模拟被测方法的执行。测试使用模拟对象来验证结果是否正确

Stub 是在测试包中创建一个模拟方法，用于替换被测代码中的方法，断言针对被测类执行。

下面是代码示例：

实际代码：

//auth.go
// 假设我们有一个依赖 http 请求的鉴权接口
type AuthService interface{Login(username string,password string) (token string,e error)   
    Logout(token string) error
}

Mock 代码：

//auth_test.go
type authService struct {}
func (auth *authService) Login (username string,password string) (string,error){return "token", nil}
func (auth *authService) Logout(token string) error{return nil}

在测试代码中使用 authService 实现了 AuthService 接口，这样测试时可以模拟外部的网络的请求，解除依赖。

这里使用的是 golang 代码，golang 不支持重载，这样使用的问题是会产生大量重复的代码。
如果是 python、java 等支持重载的面向对象语言，可以简单的继承父类，只重载包含外部请求的代码就可以实现 Mock 的需求。

package ut

func notifyUser(username string){// 如果是管理员，发送登录提醒邮件}

type AuthService struct{}

func (auth *AuthService) Login(username string, password string) (string, error) {notifyUser(username)
    return "token", nil
}
func (auth *AuthService) Logout(token string) error {return nil}

对于这段代码想要测试其实是比较困难的，因为 Login 中调用了 notifyUser，如果想测试这段代码：

一个方式是使用 Mock 的形式，定义 authService 接口，然后实现接口 TestAuthService，在 TestAuthService Login 中替换掉 notifyUser。这种做法改动比较大，同时重复代码也比较多（当然如果是 python java 等支持重载的语言可以只重载 Login 接口即可。
还有一种方法就是重构 Login 方法，把 notifyUser 作为参数传入其中，这样，我们只需在测试代码中重新定义 notifyUser，然后作为参数传入到 Login 即可模拟发送邮件提醒的功能。

第二种就是 stub 的方式。

通过这个例子我们也可以看到，如果想要代码容易测试，代码在设计时就应该考虑可测试性。

Writing Testable Code 中提到一个非常实用的观点：在开发时，多想想如何使得自己的代码更方便去测试。如果考虑到这些，那么通常你的代码设计也不会太差。

如果代码中出现了以下情况，那么通常是不易于测试的：

在构造函数或成员变量中出现 new 关键字
在构造函数或成员变量中使用 static 方法
在构造函数中有除了字段赋值外的其它操作
在构造函数中使用条件语句或者循环
在构造函数中没有使用 builder 或 factory 方法，二十使用 object graph 来构造
增加或使用初始化代码

这篇文章地址为：http://misko.hevery.com/attac… 推荐阅读。

也可以在公号回复「test」获取 pdf

总结一下就是编写可测试代码，使用高质量单元测试（命名清晰、功能简单、路径完整、数据可靠）保证代码质量。

搞定 Go 单元测试（一）——基础原理
Guide Writing Testable Code
Selective Unit Testing – Costs and Benefits
版本上线拜哪个神仙比较灵验？

最后，感谢女朋友支持和包容，比❤️

也可以在公号输入以下关键字获取历史文章：公号 & 小程序 | 设计模式 | 并发 & 协程

学习单元测试告别祈祷式编程

祈祷式编程

祈祷式编程

单元测试

什么是单元测试

单元测试的结构

如何编写好的单元测试

单元测试路径

单元测试数据

私有方法如何测试

外部服务如何测试

Mock

Stub

编写可测试代码

总结

参考文章

站内搜索