前面几篇我们一路从循环、字符串、数组讲到错误处理、模块化。模块化让代码有了清晰的组织，错误处理让脚本靠得住，但还差最后一块——怎么保证改完代码后旧功能还正常？ 这就是测试要解决的问题。
写 shell 脚本的人，对测试的态度两极分化严重。一类是从来不测，认为脚本就那么几行，跑通了就完了；另一类是把它当 Python 写，动不动就上完整测试框架。其实两端的极端都不可取——shell 脚本的测试有它自己的逻辑。
这一篇我们从写可测试的代码开始，经过自己写一个 assert 框架、处理外部依赖，最后到集成测试与 CI 集成。整篇会用上一篇的部署工具作为实战例子，演示怎么给真实项目加测试。
一、shell 测试的特殊性
在聊具体怎么做之前，我们先理解 shell 脚本测试的独特之处。这些独特性决定了 shell 测试的思路跟 Python/Go 完全不同。
1.1 副作用是常态
Python 函数默认是纯的——给定输入返回输出，不动外部世界。shell 函数不一样，很多看起来是函数的东西本质是命令调用：
# 这不是"纯函数"，是带副作用的命令链
deploy_to_production() {
ssh prod-server "systemctl restart myapp" # 远程命令
rm -rf /tmp/deploy_cache # 删文件
curl -X POST https://api.example.com/log # 调 API
}
这种函数很难直接测试——你调一次它就真去连服务器、删文件、发请求了。shell 测试的核心挑战就是把这些副作用隔离开。
1.2 全局状态共享
# 脚本顶部定义的变量
ENV="production"
DB_HOST="localhost"
# 中间的函数引用了它们
connect_db() {
echo "Connecting to $DB_HOST"
}
这个 connect_db 函数看起来是纯函数，实际依赖了文件作用域的 $DB_HOST。不设置这个变量就调它，行为完全不可预期。
Python 的类有 self 隔离，Go 的闭包有显式捕获，shell 什么都是全局的。测试 shell 函数必须显式控制输入和环境。
1.3 状态难清理
test_log_writes_to_file() {
log "test message" /var/log/test.log
cat /var/log/test.log
}
第一次跑没问题，第二次跑因为文件已存在可能就出问题了；测试完了 /var/log/test.log 还在污染系统。shell 测试需要严格的测试间隔离。
1.4 退出码的非黑即白
shell 里成功和失败是单一信号——退出码 0 或非 0。这跟 Python 的异常、Go 的 error 不同，没有半成功或特定错误类型。要区分找不到文件失败和权限不足失败，得自己定义退出码或捕获 stderr。
理解了这些特殊性，我们就有了一个心智基础。shell 测试不是套个测试框架那么简单，它要解决三个问题：怎么隔离副作用、怎么控制输入、怎么表达"预期失败" 。
二、写可测试的代码
代码可测试不是测试阶段才考虑的事情——它是设计阶段就该想清楚的。这一节讲怎么写容易被测的 shell 函数。
2.1 函数即单元
最常见的反模式是脚本式——所有逻辑写在文件顶层，没有函数封装：
# 不可测试的写法
LOG_LEVEL=INFO
load_config() { ... }
config=$(load_config)
if [[ "$config" == "production" ]]; then
ssh prod ...
fi
这种代码没法单独测 load_config 的某段逻辑——因为它执行了副作用。改成函数式：
# 可测试的写法
load_config() {
local file=$1
# ... 只做"读+解析"
echo "$parsed_config"
}
if [[ "$(load_config env.conf)" == "production" ]]; then
ssh prod ...
fi
把所有做事的代码包进函数，每个函数只做一件事，顶层只负责调用+编排。这样每个函数可以独立测试。
2.2 接受输入而不是依赖全局
# 难测试：依赖全局变量
deploy() {
ssh "$DEPLOY_HOST" "systemctl restart myapp"
}
# 易测试：显式参数
deploy() {
local host=$1
ssh "$host" "systemctl restart myapp"
}
第二种写法更易测——传不同 host 就能测不同分支，不需要改全局状态。写函数时养成所有外部依赖都从参数传的习惯。
2.3 把副作用集中到一处
如果一个函数同时做了算东西和做事情，测起来很痛苦。把它们分开：
# 难测：函数混合了"计算"和"执行"
deploy_all() {
local servers=$(list_servers)
for s in $servers; do
deploy $s
done
}
# 易测：先计算再执行，分开测
get_servers_to_deploy() {
local servers=$(list_servers)
echo "$servers"
}
deploy() {
local host=$1
ssh "$host" "systemctl restart myapp"
}
# 顶层编排（集成测试覆盖）
for s in $(get_servers_to_deploy); do
deploy $s
done
get_servers_to_deploy 是纯计算（无副作用），deploy 是有副作用的命令，两者分开测：get_servers_to_deploy 测逻辑，deploy 测集成行为。
2.4 早返回代替嵌套
# 难读也难测
process_file() {
if [ -f "$1" ]; then
if [ -r "$1" ]; then
# ... 实际逻辑
return 0
else
return 1
fi
else
return 1
fi
}
# 易读也易测
process_file() {
local file=$1
[ -f "$file" ] || return 1
[ -r "$file" ] || return 1
# ... 实际逻辑
return 0
}
第二种写法叫"早返回"（early return）。每种失败场景一行就能测——比如 process_file "/nonexistent" 测的就是文件不存在的失败路径。
2.5 配置文件用环境变量或参数传入
上一篇我们的 load_config 函数接收文件名作为参数。这意味着测试时可以传任何临时文件，不需要污染真实配置。
# 测试时
load_config "/tmp/test_config_$$"
$$ 是进程 ID，每个测试用例的文件都是独立的。
三、自己写一个轻量 assert 框架
shell 测试的核心是判断实际行为是否等于预期行为。这个判断需要一组"断言"函数。Python 有 unittest.assertEqual，shell 里我们就自己写。
3.1 最基本的 assert 函数
# tests/lib_test.sh - 测试工具库
[[ -n "${_LIB_TEST_LOADED:-}" ]] && return
_LIB_TEST_LOADED=1
# 测试统计
TESTS_RUN=0
TESTS_PASSED=0
TESTS_FAILED=0
FAILED_TESTS=()
# ============================================================
# 断言函数
# ============================================================
# 通用失败处理
_assert_fail() {
local test_name=$1
local message=$2
local actual=$3
local expected=$4
echo " ✗ $test_name" >&2
echo " 消息: $message" >&2
if [[ -n "$expected" ]]
then
echo " 期望: $expected" >&2
echo " 实际: $actual" >&2
fi
FAILED_TESTS+=("$test_name")
((TESTS_FAILED++)) || true
}
# assert_eq <测试名> <实际值> <期望值> [消息]
assert_eq() {
local test_name=$1
local actual=$2
local expected=$3
local message=${4:-}
((TESTS_RUN++)) || true
if [[ "$actual" == "$expected" ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "$actual" "$expected"
fi
}
# assert_contains <测试名> <实际值> <期望子串> [消息]
assert_contains() {
local test_name=$1
local actual=$2
local expected=$3
local message=${4:-}
((TESTS_RUN++)) || true
if [[ "$actual" == *"$expected"* ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "$actual" "包含 '$expected'"
fi
}
# assert_success <测试名> <退出码> [消息]
assert_success() {
local test_name=$1
local actual=$2
local message=${3:-}
((TESTS_RUN++)) || true
if [[ "$actual" -eq 0 ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "$actual" "0"
fi
}
# assert_failure <测试名> <退出码> [消息]
assert_failure() {
local test_name=$1
local actual=$2
local message=${3:-}
((TESTS_RUN++)) || true
if [[ "$actual" -ne 0 ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "$actual" "非零"
fi
}
# assert_true <测试名> <实际值> [消息]
assert_true() {
local test_name=$1
local actual=$2
local message=${3:-}
((TESTS_RUN++)) || true
if [[ "$actual" == "true" || "$actual" == "0" ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "$actual" "true"
fi
}
# assert_file_exists <测试名> <文件路径> [消息]
assert_file_exists() {
local test_name=$1
local file=$2
local message=${3:-}
((TESTS_RUN++)) || true
if [[ -f "$file" ]]
then
echo " ✓ $test_name" >&2
((TESTS_PASSED++)) || true
else
_assert_fail "$test_name" "$message" "文件不存在: $file" "文件存在"
fi
}
# ============================================================
# 测试汇总
# ============================================================
print_summary() {
echo "" >&2
echo "========================================" >&2
echo "测试结果" >&2
echo "========================================" >&2
echo "运行: $TESTS_RUN, 通过: $TESTS_PASSED, 失败: $TESTS_FAILED" >&2
if [[ $TESTS_FAILED -gt 0 ]]
then
echo "" >&2
echo "失败的测试:" >&2
for t in "${FAILED_TESTS[@]}"
do
echo " - $t" >&2
done
return 1
fi
echo "全部通过！" >&2
return 0
}
这个 assert 库覆盖了 shell 测试里 90% 的断言需求：
assert_eq：值相等assert_contains：包含子串assert_success/assert_failure：退出码判断assert_true：布尔判断assert_file_exists：文件存在print_summary：汇总
所有错误信息输出到 stderr（>&2），不影响 stdout 拿测试结果。所有测试函数都把测试结果累积到全局变量里（这是 shell 测试的妥协——必须有共享状态）。
3.2 一个完整的测试用例
# tests/test_log.sh - 日志库测试
source "$(dirname "${BASH_SOURCE[0]}")/../lib/lib_log.sh"
source "$(dirname "${BASH_SOURCE[0]}")/lib_test.sh"
# 测试 1: log_info 输出格式正确
test_log_info_format() {
local output
output=$(LOG_LEVEL=INFO log_info "test message" 2>&1)
assert_contains "log_info 包含时间戳" "$output" "["
assert_contains "log_info 包含级别" "$output" "[INFO]"
assert_contains "log_info 包含消息" "$output" "test message"
}
# 测试 2: 日志级别过滤
test_log_level_filter() {
# DEBUG 级别在默认 LOG_LEVEL=INFO 下应该不输出
local output
output=$(LOG_LEVEL=INFO log_debug "debug message" 2>&1)
assert_eq "LOG_LEVEL=INFO 时 debug 不输出" "$output" ""
# 但当 LOG_LEVEL=DEBUG 时应该输出
output=$(LOG_LEVEL=DEBUG log_debug "debug message" 2>&1)
assert_contains "LOG_LEVEL=DEBUG 时 debug 输出" "$output" "debug message"
}
# 测试 3: 日志输出到文件
test_log_to_file() {
local tmpfile="/tmp/test_log_$$"
LOG_LEVEL=INFO LOG_FILE="$tmpfile" log_info "to file" 2>/dev/null
assert_file_exists "日志文件被创建" "$tmpfile"
local content
content=$(cat "$tmpfile")
assert_contains "文件包含消息" "$content" "to file"
rm -f "$tmpfile"
}
# ============================================================
# 测试入口
# ============================================================
echo "运行 test_log.sh ..." >&2
test_log_info_format
test_log_level_filter
test_log_to_file
print_summary
跑测试：
$ bash tests/test_log.sh
运行 test_log.sh ...
✓ log_info 包含时间戳
✓ log_info 包含级别
✓ log_info 包含消息
✓ LOG_LEVEL=INFO 时 debug 不输出
✓ LOG_LEVEL=DEBUG 时 debug 输出
✓ 日志文件被创建
✓ 文件包含消息
========================================
测试结果
========================================
运行: 7, 通过: 7, 失败: 0
全部通过！
跟 Python 的 pytest 比，这个测试框架丑得多——没有自动发现、没有参数化、没有 fixture。但它能用，日常 shell 测试够用了。
3.3 test 包装器
如果想让某个 assert 失败时整个测试函数立刻停止，可以加个包装器：
# 测试函数包装器
run_test() {
local test_func=$1
echo "" >&2
echo "[$test_func]" >&2
# 每个测试前重置失败计数（局部）
local failed_before=$TESTS_FAILED
"$test_func"
local failed_after=$TESTS_FAILED
if [[ $failed_after -gt $failed_before ]]
then
echo " 测试 $test_func 有失败" >&2
fi
}
或者用 set +e 包裹单个 assert 块：
test_something() {
set +e
assert_eq "case 1" "a" "b" # 这个失败不退出
assert_eq "case 2" "c" "d" # 这个继续测
set -e
}
shell 测试的控制流比 Python 麻烦得多，但只要你写的函数小、断言集中，复杂度不会爆。
四、处理外部依赖
shell 函数的外部依赖主要分三类：文件系统、网络、外部命令。这一节我们看怎么假装这些依赖，让测试跑得又快又稳。
4.1 临时目录隔离文件系统
测试涉及文件时，永远用临时目录，不要污染真实文件系统：
setup_tmpdir() {
TEST_TMPDIR=$(mktemp -d /tmp/shell_test.XXXXXX)
trap "rm -rf '$TEST_TMPDIR'" EXIT
}
# 在每个测试函数开头调用
test_something() {
setup_tmpdir
# 在 $TEST_TMPDIR 里建文件、操作、断言
touch "$TEST_TMPDIR/test_file"
assert_file_exists "文件被创建" "$TEST_TMPDIR/test_file"
}
mktemp -d 创建独立目录，$$ 保证唯一性，trap "rm -rf" EXIT 清理。这是 shell 测试的标准卫生。
4.2 PATH 隔离外部命令
测试用了 curl、ssh 这类命令时，不能让测试真的发请求。最简单的方法是替换 PATH：
# tests/test_deploy.sh
source "$(dirname "${BASH_SOURCE[0]}")/../lib/lib_common.sh"
source "$(dirname "${BASH_SOURCE[0]}")/lib_test.sh"
# 创建 mock 工具目录
MOCK_BIN=$(mktemp -d)
# 创建假的 curl（不真发请求，只记录调用）
cat > "$MOCK_BIN/curl" <<'EOF'
#!/bin/bash
echo "MOCK curl called: $*" >> /tmp/mock_calls.log
echo "Mock response"
EOF
chmod +x "$MOCK_BIN/curl"
# 把 mock 目录加到 PATH 最前面
export PATH="$MOCK_BIN:$PATH"
# 测试时调用 curl，实际执行的是 mock 版本
test_deploy_calls_api() {
rm -f /tmp/mock_calls.log
deploy_to_api "https://example.com" "data"
assert_file_exists "mock 日志被创建" /tmp/mock_calls.log
assert_contains "curl 被调用" "$(cat /tmp/mock_calls.log)" "curl"
}
test_deploy_calls_api
PATH="$MOCK_BIN:$PATH" 让脚本里的 curl 命令实际执行的是我们写的 mock 脚本。这是 shell 测试的核心技巧——通过修改环境变量，替换掉任何外部命令。
4.3 函数级别的 mock
如果被测函数调用了其他 shell 函数，可以用同名的空函数覆盖：
# tests/test_deploy.sh
# 真实函数：会去连服务器
deploy_to_server() {
local host=$1
ssh "$host" "systemctl restart myapp"
}
# 测试时覆盖：什么都不做，只记录参数
deploy_to_server() {
echo "MOCK deploy_to_server: $1" >> /tmp/mock_calls.log
return 0
}
# 现在调用 deploy_to_server 执行的是 mock 版本
test_deploy() {
rm -f /tmp/mock_calls.log
main_deploy "dev"
assert_contains "deploy_to_server 被调用" "$(cat /tmp/mock_calls.log)" "deploy_to_server"
}
但这有个问题：被覆盖的函数必须先 source 或定义过。如果原函数是在被测脚本里定义的，测试文件要先 source 那个脚本，然后重新定义同名函数。
4.4 处理时间依赖
很多脚本依赖 date、sleep、cron 时间。测试时怎么控制？
方案一：接受一个"时间函数"参数。
# 不好的写法
is_expired() {
local expiry=$1
[[ $(date +%s) -gt $expiry ]]
}
# 好的写法
is_expired() {
local expiry=$1
local now=${2:-$(date +%s)} # 默认用真实时间，但可以传入
[[ "$now" -gt "$expiry" ]]
}
# 测试
test_is_expired() {
# 模拟当前时间是 2024-01-01
local fake_now=$(date -d "2024-01-01" +%s)
local expiry=$(date -d "2024-12-31" +%s)
assert_false "未过期" "$(is_expired "$expiry" "$fake_now" && echo true || echo false)"
}
方案二：用环境变量覆盖 date 命令。
# 提供 mock 的 date
cat > "$MOCK_BIN/date" <<'EOF'
#!/bin/bash
# 测试时固定返回 2024-01-01
case "$*" in
"+%s")
echo "1704067200" # 2024-01-01 00:00:00 UTC
;;
*)
/usr/bin/date "$@"
;;
esac
EOF
chmod +x "$MOCK_BIN/date"
方案三：把时间作为变量存到全局。
CURRENT_TIME=${CURRENT_TIME:-$(date +%s)}
is_expired() {
local expiry=$1
[[ "$CURRENT_TIME" -gt "$expiry" ]]
}
测试时：
CURRENT_TIME="1704067200" is_expired "..."
三种方案各有适用场景，第一种最干净（函数显式接受时间参数），第三种最简单（适合小脚本），第二种最灵活（适合时间依赖复杂的场景）。
4.5 处理网络和数据库
网络和数据库是 shell 测试里最难完全 mock的——它们有协议、有状态、有副作用。常见做法：
网络（curl、ssh、scp） ：用 PATH mock（4.2 节）。或者用 nc 启动本地假服务。
数据库（mysql、psql） ：同样 PATH mock，模拟返回结果。
第三方 API：用 PATH mock 替换 curl。复杂的接口可以用 python -m http.server 启本地假服务。
实操建议：业务脚本里把调用外部 API封装成函数：
# lib_api.sh
api_call() {
local endpoint=$1
curl -s "https://api.example.com/$endpoint"
}
# 测试时
api_call() {
echo '{"status":"ok","data":[]}' # mock 返回
}
单一封装点让 mock 简单太多——你只需要覆盖一个函数，就能假装调过 API。
五、测试组织
随着测试用例增多，怎么组织是个问题。这一节讲一个小而全的测试目录结构。
5.1 标准 tests 目录
project/
├── bin/
├── lib/
├── src/
└── tests/
├── lib_test.sh # 测试工具库
├── test_log.sh # log 库测试
├── test_config.sh # config 库测试
├── test_deploy.sh # deploy 业务测试
├── test_integration.sh # 集成测试
├── fixtures/ # 测试数据
│ ├── config_valid.conf
│ └── config_invalid.conf
└── run_all_tests.sh # 测试入口
test_*.sh 命名让测试自动发现变得简单——任何 test_*.sh 文件都是一个测试套件。
5.2 测试入口：run_all_tests.sh
#!/bin/bash
# tests/run_all_tests.sh - 运行所有测试
set -euo pipefail
SCRIPT_DIR=$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)
PROJECT_ROOT=$(cd "$SCRIPT_DIR/.." && pwd)
# 加载测试工具
source "$SCRIPT_DIR/lib_test.sh"
# 找到所有测试文件
test_files=("$SCRIPT_DIR"/test_*.sh)
if [[ ${#test_files[@]} -eq 0 ]]
then
echo "没找到测试文件" >&2
exit 1
fi
echo "找到 ${#test_files[@]} 个测试文件" >&2
echo "" >&2
# 累计统计
TOTAL_RUN=0
TOTAL_PASSED=0
TOTAL_FAILED=0
# 运行每个测试文件
for test_file in "${test_files[@]}"
do
if [[ "$(basename "$test_file")" = "lib_test.sh" || "$(basename "$test_file")" = "run_all_tests.sh" ]]
then
continue
fi
echo "运行 $(basename "$test_file") ..." >&2
echo "----------------------------------------" >&2
# 重置计数器
TESTS_RUN=0
TESTS_PASSED=0
TESTS_FAILED=0
FAILED_TESTS=()
# 跑测试
if bash "$test_file"
then
: # 测试文件本身成功
else
: # print_summary 会返回非零
fi
TOTAL_RUN=$((TOTAL_RUN + TESTS_RUN))
TOTAL_PASSED=$((TOTAL_PASSED + TESTS_PASSED))
TOTAL_FAILED=$((TOTAL_FAILED + TESTS_FAILED))
done
# 打印总结
echo "" >&2
echo "========================================" >&2
echo "总测试结果" >&2
echo "========================================" >&2
echo "运行: $TOTAL_RUN, 通过: $TOTAL_PASSED, 失败: $TOTAL_FAILED" >&2
if [[ $TOTAL_FAILED -gt 0 ]]
then
exit 1
fi
exit 0
跑所有测试：
$ bash tests/run_all_tests.sh
找到 4 个测试文件
运行 test_log.sh ...
----------------------------------------
✓ log_info 包含时间戳
...
========================================
总测试结果
========================================
运行: 28, 通过: 27, 失败: 1
任意测试失败，整个脚本退出非零——这正是 CI 系统所需要的信号。
5.3 fixtures：测试数据
复杂的测试需要测试夹具——预先准备好的输入数据：
# tests/fixtures/config_valid.conf
DB_HOST=localhost
DB_PORT=3306
DB_USER=admin
DB_PASSWORD=secret
# tests/test_config.sh
test_load_valid_config() {
source "$(dirname "${BASH_SOURCE[0]}")/../lib/lib_config.sh"
local config="$SCRIPT_DIR/fixtures/config_valid.conf"
load_config "$config"
assert_eq "DB_HOST 加载正确" "$DB_HOST" "localhost"
assert_eq "DB_PORT 加载正确" "$DB_PORT" "3306"
assert_eq "DB_USER 加载正确" "$DB_USER" "admin"
}
test_load_missing_config() {
source "$(dirname "${BASH_SOURCE[0]}")/../lib/lib_config.sh"
local missing="/tmp/nonexistent_$$"
local exit_code=0
load_config "$missing" || exit_code=$?
assert_failure "加载不存在的配置应该失败" "$exit_code"
}
fixture 文件只放在 tests/fixtures/ 里，生产代码和测试代码完全分离。
5.4 setUp / tearDown 模式
Python 的 unittest 有 setUp 和 tearDown 在每个测试前后执行。shell 里可以用包装函数模拟：
# tests/lib_test.sh
# 测试计数器
TEST_COUNT=0
# 每个测试前的初始化
setUp() {
TEST_COUNT=$((TEST_COUNT + 1))
TEST_TMPDIR=$(mktemp -d /tmp/shell_test.XXXXXX)
export TEST_TMPDIR
}
# 每个测试后的清理
tearDown() {
if [[ -n "$TEST_TMPDIR" && -d "$TEST_TMPDIR" ]]
then
rm -rf "$TEST_TMPDIR"
fi
}
# 测试包装器
run_test() {
local test_func=$1
setUp
"$test_func"
local exit_code=$?
tearDown
return $exit_code
}
使用：
test_log_writes_to_file() {
local logfile="$TEST_TMPDIR/test.log"
LOG_FILE="$logfile" log_info "hello"
assert_file_exists "日志文件被创建" "$logfile"
}
# 注册测试
run_test test_log_writes_to_file
run_test 自动处理 setUp 和 tearDown，每个测试都跑在独立的临时目录里。
六、集成测试
单元测试验证函数对不对，集成测试验证组合起来能不能跑。这一节看几个典型的集成测试场景。
6.1 端到端脚本测试
# tests/test_integration.sh
source "$(dirname "${BASH_SOURCE[0]}")/lib_test.sh"
source "$(dirname "${BASH_SOURCE[0]}")/../lib/lib_common.sh"
PROJECT_ROOT=$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)
SCRIPT="$PROJECT_ROOT/bin/myscript"
test_help_command() {
local output
output=$("$SCRIPT" --help 2>&1)
local exit_code=$?
assert_success "--help 退出码为 0" "$exit_code"
assert_contains "帮助信息提到用法" "$output" "用法"
}
test_missing_args() {
local output
output=$("$SCRIPT" 2>&1)
local exit_code=$?
assert_failure "无参数应该失败" "$exit_code"
assert_contains "错误信息提到用法" "$output" "用法"
}
test_version_flag() {
local output
output=$("$SCRIPT" --version 2>&1)
assert_contains "版本号被输出" "$output" "1.0.0"
}
test_help_command
test_missing_args
test_version_flag
print_summary
集成测试不 mock，直接调脚本。它验证的是脚本作为整体能跑，单元测试覆盖不到的边界条件在这里兜底。
6.2 用临时环境跑完整流程
部署类脚本的集成测试可以这样设计：用临时目录当生产环境，跑完整的部署流程，验证最终状态。
# tests/test_deploy_integration.sh
setup_test_env() {
# 创建模拟的"远端服务器"目录
export FAKE_REMOTE=$(mktemp -d)
mkdir -p "$FAKE_REMOTE/app"
echo "v1.0.0" > "$FAKE_REMOTE/app/VERSION"
# 替换 SSH 为本地 cp
cat > "$FAKE_REMOTE/ssh" <<EOF
#!/bin/bash
# mock ssh: 第一个参数是"主机"，忽略它，执行后面的命令
shift
eval "$*"
EOF
chmod +x "$FAKE_REMOTE/ssh"
export PATH="$FAKE_REMOTE:$PATH"
}
test_full_deploy_workflow() {
setup_test_env
local config="$TEST_TMPDIR/deploy.conf"
cat > "$config" <<EOF
DEPLOY_HOST=fake-host
DEPLOY_USER=tester
APP_VERSION=v1.2.0
EOF
# 调用部署脚本
"$PROJECT_ROOT/bin/deploy" deploy dev
# 验证最终状态
local version
version=$(cat "$FAKE_REMOTE/app/VERSION")
assert_eq "版本被更新" "$version" "v1.2.0"
}
集成测试比单元测试慢，但它验证的是真实场景下能跑。日常开发可以只跑单元测试，发布前跑一遍集成测试。
6.3 在 CI 里跑测试
最后一步是把测试接到 CI 系统里。GitHub Actions 示例：
# .github/workflows/test.yml
name: Tests
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run shell tests
run: bash tests/run_all_tests.sh
- name: Check exit code
run: exit 0
bash tests/run_all_tests.sh 非零退出时，CI 任务直接标红。任何合并到主干的 PR 都必须通过测试。
七、总结
shell 脚本测试跟其他语言不一样——它没有像 pytest 那样开箱即用的框架，但核心思路是一致的：写可测试的代码、用 assert 表达预期、隔离副作用、组织测试、接入 CI。这一篇我们覆盖了完整流程：
- 可测试的代码：函数化、显式参数、副作用分离、早返回
- assert 函数：自己写一套轻量的断言库，足够覆盖 90% 场景
- 外部依赖：用临时目录、PATH mock、函数覆盖、时间注入
- 测试组织：tests 目录、fixtures、run_all_tests.sh 入口
- 集成测试：端到端验证、CI 集成
最重要的认知是：shell 测试不是套框架那么简单，它要解决副作用隔离、状态控制、退出码表达这几个特殊问题。理解了这些，自己的 assert 库、自己的 mock 方案、自己的测试组织——都是水到渠成的事。
本文示例在 GNU bash 4.3+ 环境下测试通过。
mktemp -d在所有主流系统上都有。PATHmock 在所有 POSIX 系统上工作。CI 集成示例用的是 GitHub Actions，其他 CI 系统（GitLab CI、Jenkins）的配置大同小异。
