在正式的场景,代码写完后都是需要测试的,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 脚本的测试方法,以及编写可测试代码的方法。