如何有效测试你的 Bash 脚本

Bash 脚本常常涉及文件、服务、部署和生产数据。有效测试你的 Bash 脚本有助于在清理任务删除错误目录或部署脚本跳过失败命令之前，捕捉错误的假设。

你不需要一个庞大的框架来开始。结合防御性 shell 选项、静态检查、聚焦的单元测试和临时测试环境，让你的脚本能够大声且可预测地失败。

基础：防御性编码与调试

在实施正式的单元测试之前，防御 bug 的第一层防线在于脚本本身的结构。利用严格的操作设置可以帮助将微小的运行时错误转化为即时失败，使其更易于调试。

必要的防御性头部

许多生产 Bash 脚本以更严格的选项开头：

#!/bin/bash
# 如果命令以非零状态退出，则立即退出。
set -e

# 在替换时将未设置的变量视为错误。
set -u

# 防止管道中的错误被掩盖。
set -o pipefail

将这些组合成 set -euo pipefail 是很常见的。请注意，set -e 在条件语句、子 shell 和管道中存在边缘情况，因此仍需显式检查预期的失败，而不是假设严格模式可以替代测试。

使用追踪进行手动调试

为了快速调试或理解脚本执行流程，Bash 提供了内置的追踪功能：

命令追踪 (-x)： 在执行时打印命令及其参数，前缀为 +。
不执行 (-n)： 读取命令但不执行（用于检查语法错误）。

你可以在运行脚本时启用追踪，也可以在脚本内部启用：

# 使用追踪运行脚本
bash -x ./my_script.sh

# 在脚本内部为特定部分启用追踪
echo "开始复杂操作..."
set -x # 启用追踪
complex_function_call arg1 arg2
set +x # 禁用追踪
echo "操作完成。"

采用正式的单元测试框架

对于复杂逻辑，手动调试是不可持续的。正式的单元测试框架允许你定义可重复的测试用例，断言预期结果，并自动化验证过程。

1. Bats（Bash 自动化测试系统）

Bats 可以说是最流行且最简单的 Bash 测试框架。它允许你使用熟悉的 Bash 语法编写测试，使断言简单且可读。

Bats 的主要特性：

测试使用类似 Bash 的语法编写。
使用简单的 run 命令执行目标脚本/函数。
提供内置的断言变量，如 $status、$output 和 $lines。

示例：测试一个简单函数

假设你有一个脚本（calculator.sh），其中包含一个函数 calculate_sum。

calculator.sh 片段：

calculate_sum() {
  if [[ $# -ne 2 ]]; then
    echo "错误：需要两个参数" >&2
    return 1
  fi
  echo $(( $1 + $2 ))
}

test/calculator.bats：

#!/usr/bin/env bats

# 引入包含待测试函数的脚本。
# BATS_TEST_DIRNAME 指向包含此测试文件的目录。
source "$BATS_TEST_DIRNAME/../calculator.sh"

@test "有效输入应返回正确的和" {
  run calculate_sum 10 5
  # 断言函数返回成功状态（0）
  [ "$status" -eq 0 ]
  # 断言输出与预期匹配
  [ "$output" = "15" ]
}

@test "缺少输入应返回错误状态（1）" {
  run calculate_sum 5
  [ "$status" -ne 0 ]
  [ "$status" -eq 1 ]
  # 在较新的 bats-core 版本中，使用 `run` 时可以访问 stderr。
  # [ "$stderr" = "错误：需要两个参数" ] 
}

要运行测试：

bats test/calculator.bats

2. ShUnit2

ShUnit2 遵循 xUnit 风格的测试，使来自 Python 或 Java 等语言的开发者感到熟悉。它需要引入框架文件，并遵循严格的命名约定（setUp、tearDown、test_...）。

ShUnit2 的主要特性：

支持用于清理的 setup 和 teardown 例程。
提供丰富的内置断言函数（例如 assertTrue、assertEquals）。

ShUnit2 结构

#!/bin/bash
# 引入 shUnit2。根据你的安装调整此路径。
. /usr/local/share/shunit2/shunit2

# 定义变量/夹具

setUp() {
  # 在每个测试之前运行的代码
  TEMP_FILE=$(mktemp)
}

tearDown() {
  # 在每个测试之后运行的代码（清理）
  rm -f "$TEMP_FILE"
}

test_basic_addition() {
  local result
  # 调用被测试的函数
  result=$(my_script_function 1 2)
  
  # 使用断言函数
  assertEquals "3" "$result"
}

# 如果你的 shUnit2 包期望在末尾显式引入，
# 则在测试函数之后而不是在开头引入它。

Bash 脚本测试的最佳实践

有效的测试不仅仅是运行一个框架；它需要仔细隔离组件并管理环境依赖关系。

1. 处理输入、输出和错误

你的测试必须验证标准流（stdout、stderr）和最终的退出代码，这是 Bash 中表示成功或失败的主要机制。

退出代码： 测试 status -eq 0 表示成功，非零值表示错误条件，如解析失败或文件缺失。
标准输出 (stdout)： 这通常是主要的数据输出。使用 Bats 的 $output 或在 ShUnit2 中捕获输出来断言正确性。
标准错误 (stderr)： 错误、警告和调试消息应路由到这里。关键是确保生产脚本在成功运行时在 stderr 上保持静默。

2. 隔离依赖关系（模拟）

单元测试应该测试你的代码，而不是外部系统工具（如 curl、kubectl 或 git）。如果你的脚本依赖于外部命令，你应该在测试期间模拟该命令。

方法： 创建一个包含与真实依赖项同名的模拟可执行文件的临时目录。在运行测试之前，将此目录添加到你的 $PATH 前面，确保你的脚本调用模拟工具而不是真实工具。

模拟示例：

#!/bin/bash
# 文件：/tmp/mock_bin/curl

if [[ "$1" == "--version" ]]; then
  echo "模拟 Curl 7.6"
  exit 0
else
  # 模拟成功的 API 响应
  echo '{"status": "ok"}'
  exit 0
fi

在你的测试设置中：

export PATH="/tmp/mock_bin:$PATH"

3. 使用临时环境进行集成测试

集成测试验证脚本是否正确与文件系统和操作系统交互。使用临时目录以避免污染系统或干扰其他测试。

使用 `mktemp`

mktemp -d 命令创建一个安全、唯一的临时目录。你应该在测试运行期间在此目录内执行所有文件操作（创建、修改、清理）。

setUp() {
  # 为此测试运行创建一个临时目录
  TEST_ROOT=$(mktemp -d)
  cd "$TEST_ROOT"
}

tearDown() {
  # 清理临时目录
  cd - >/dev/null
  rm -rf "$TEST_ROOT"
}

@test "脚本应创建所需的日志文件" {
  run my_script_that_writes_logs
  
  # 断言临时目录中存在预期的文件
  [ -f "./log/script.log" ]
}

4. 测试可移植性

Bash 实现略有不同（例如 GNU Bash 与 macOS/BSD Bash）。如果可移植性是一个问题，可以在各种目标环境（例如使用 Docker 容器）上运行你的测试套件，以捕捉实用命令或参数扩展中的细微差异。

将测试集成到工作流中

测试不应是事后才考虑的事情。将你的测试套件集成到版本控制和 CI/CD（持续集成/持续部署）管道中。

版本控制： 将测试目录（例如 test/）与你的源脚本一起存储。
预提交钩子： 使用像 shellcheck（一个静态分析工具）和格式化工具来确保提交前的代码质量。
CI 自动化： 配置你的 CI 服务器（GitHub Actions、GitLab CI、Jenkins）在每次推送时自动执行 Bats 或 ShUnit2 测试套件。如果任何测试返回非零状态，则构建失败。

警告： 像 shellcheck 这样的静态分析工具是单元测试的优秀伴侣。它们能捕捉测试可能遗漏的常见错误、可移植性问题和安全漏洞。始终将 shellcheck 作为预测试例程的一部分运行。

结论

从 shellcheck 和 set -euo pipefail 开始，然后围绕脚本中解析输入、选择文件、调用外部工具或进行不可逆更改的部分添加测试。一个带有模拟依赖项和临时目录的小型 Bats 套件通常足以将一个有风险的脚本转变为你可以放心更改的自动化工具。