Zsh 开发指南（第二十一篇 测试方法以及编写可测试代码的方法）

导读

在正式的场景，代码写完后都是须要测试的，shell 脚本也不例外。但 shell 脚本的特性致使测试方法和其余语言有所不一样。

单元测试

做为一种重要的测试方法，单元测试在不少种编程语言程序测试中起到举重轻重的做用。但不幸的是，单元测试基本不适用于 shell 脚本。并非说 shell 脚本不能被单元测试，而是说单元测试能测试出来的问题不多，投入却很大。为了让 shell 脚本能被单元测试，50 行的代码极可能要改写成 100 多行甚至更多行。更重要的是 shell 脚本严重依赖外部环境，多数问题须要对脚本总体进行功能测试才能发现，而不是对单个函数进行单元测试。对单元测试的精力投入极可能会减小在功能测试的精力投入。

因此不建议推行 shell 脚本的单元测试，这不只会让开发者很痛苦，也很难减小问题的出现概率，甚至有可能拔苗助长。

单个脚本的功能测试

Shell 脚本的最小测试粒度是单个脚本。必须保证单个脚本是容易测试的，不能多个脚本耦合太紧密而难以对其中某一个进行单独测试。

有主体逻辑的脚本依赖的外部环境必须是容易模拟的。好比须要从数据库中读取数据，对数据进行处理，而后写入到文件中，这些功能不能在同一个脚本中完成。由于数据库这个外部环境不容易模拟，会致使测试困难。须要把读写数据库的功能独立成单独的脚本，功能尽可能简单，测试该脚本时只须要关心数据是否正常读取了出来，格式是否被正确转换等等，而不须要关心处理数据的具体逻辑。处理数据的主体逻辑代码要独立成一个（或者多个）脚本，测试该脚本时，无需准备数据库环境，直接用另外一个脚本或者数据文件取代读取数据库的脚本，提供测试数据。若是文件写入的环境复杂（好比文件或者目录结构复杂，或者要写入到分布式文件系统等等），也须要将文件写入的脚本独立出来以便更易于测试。

对有主体逻辑的脚本进行功能测试，不能手动进行，必须写测试脚本，能够自动运行。每次脚本改动后进行回归测试。项目稳定后，能够在每次提交代码后自动运行测试脚本。测试脚本必须覆盖正常和异常状况，不能只覆盖正常状况。异常状况的多少，要根据脚本的复杂度而定。

有复杂外部依赖的脚本，功能必须单一，逻辑尽可能简单，代码尽可能稳定，不常常改动。好比读写数据库、启停进程、复杂的目录文件操做等有复杂外部依赖的脚本，功能必须单一，只与一个特定的外部依赖交互，提供尽可能和外部依赖无关的中间数据，尽可能不包含和外部环境无关的逻辑。该类脚本要容易模拟，以便在测试其余部分时再也不须要依赖外部环境。

对于有复杂外部依赖的脚本，能够写脚本自动测试，也能够手动测试，测试时须要包含正常和异常的状况，不能只测试正常状况。

功能测试示例

须要写脚本完成以下功能：

若是 process1 和 process2 两个进程都存在，以 process2 进程 cwd 目录中的 data/output.txt 为输入，作一些比较复杂的处理，而后输出到 process1 进程 cwd 目录中的 data/input.txt 文件（若是该文件已存在，则不处理），处理完后，删除以前的 data/output.txt。

分析：

process1 和 process2 两个进程都是复杂的外部依赖，不能在主体逻辑脚本里直接依赖它们，因此要把检查进程是否存在的逻辑独立成单独的脚本。输入和输出文件的路径依赖进程路径，为了测试方便，也要把获取文件路径的逻辑独立成单独的脚本。

脚本功能实现：

检查进程是否存在和获取进程 cwd 目录的 util.zsh 脚本：

#!/bin/zsh

check_process() {
    pidof $1
}

get_process_cwd() {
    readlink /proc/$1/cwd
}

主体逻辑脚本 main.zsh：

#!/bin/zsh

# 有错误即退出，能够省掉不少错误处理的代码
set -e

# 切换到脚本当前目录
cd ${0:h}

# 加载依赖的脚本
source ./util.zsh

# 检查进程是否存在
local process1_pid=$(check_process process1)
local process2_pid=$(check_process process2)

# 这里的 input 和 output 是相对脚原本说的
local input_file=$(get_process_cwd $process2_pid)/data/output.txt
local output_file=$(get_process_cwd $process1_pid)/data/input.txt

# 若是输入文件不存在，直接退出
[[ -e $input_file ]] || {
    echo $input_file not found.
    exit 1
}

# 若是输出文件已存在，也直接退出
[[ -e $output_file ]] && {
    echo $output_file already exists.
    exit 0
}

# 处理 $input_file 内容
# 省略

# 将结果输出到 $output_file
# 省略

功能测试方法：

util.zsh 里的两个函数功能过于简单，无需测试。

测试 main.zsh 时，须要构造一系列测试用的 util.zsh，用于模拟各类状况：

# 进程存在的状况
check_process() {
    echo $$
}

# 进程不存在的状况
check_process() {
    return 1
}

# 进程 process1 存在而 process2 不存在的状况
check_process() {
    [[ $1 == process1 ]] && echo 1234 && return
    [[ $1 == process2 ]] && return 1
}

# 输出了进程号，但实际进程不存在的状况
check_process() {
    echo 0
}

# 其余状况
# 省略


# 路径存在的状况
get_process_cwd() {
    [[ $1 == process1 ]] && echo /path/to/cwd1 && return
    [[ $1 == process2 ]] && echo /path/to/cwd2 && return
}

# 路径不存在的状况
get_process_cwd() {
    return 1
}

# 输出了路径，但路径实际不存在的状况
get_process_cwd() {
    echo /wrong/path
}

# 其余状况
# 省略

而后组合这些状况，写测试脚本判断 main.zsh 的处理是否符合预期。

其中一个测试脚本样例：

util_test1.zsh 内容：

#!/bin/zsh

# 进程存在
check_process() {
    echo $$
}

# 直接返回正确的路径
get_process_cwd() {
    [[ $1 == process1 ]] && echo /path/to/cwd1 && return
    [[ $1 == process2 ]] && echo /path/to/cwd2 && return
}

test.zsh 内容：

#!/bin/zsh

# 用于测试的函数，能够独立成单独脚本以便复用
assert_ok() {
    (($1 == 0)) || {
        echo Error, retcode: $1
        exit 1
    }
}

check_output_file() {
    # 检查输出文件是否符合预期
    # 省略
}

# 应用 util_test1.zsh
ln -sf util_test1.zsh util.zsh

# 运行脚本
./main.zsh

# 检查返回值是否正常
assert_ok $?

# 检查输出文件是否符合预期
check_output_file /path/to/output/file

# 其余检查
# 省略

# 应用 util_test2.zsh
ln -sf util_test2.zsh util.zsh

# 省略

集成测试

测试完每一个脚本的功能后，须要将各个脚本以及其余程序整合起来测试互相调用过程是否正常。若是功能比较复杂，须要分批整合，测试各个逻辑单元是否能正常工做。在这部分测试中，和外部环境交互的脚本若是逻辑较为简单，能够不参与，用模拟脚本替代。能够手动测试或自动测试。一样不能只测试正常状况。

系统测试

将全部相关组件整合起来，测试整个系统或者子系统的功能。模拟脚本不能参与系统测试，必须使用真实的外部环境。系统测试一般须要手动进行，能够用自动化测试系统来辅助。须要覆盖尽量多的状况，不能只测试系统的正常功能。

总结

本文简单介绍了 shell 脚本的测试方法，以及编写可测试代码的方法。

本文再也不更新，全系列文章在此更新维护：github.com/goreliu/zshguide

付费解决 Windows、Linux、Shell、C、C++、AHK、Python、JavaScript、Lua 等领域相关问题，灵活订价，欢迎咨询，微信 ly50247。