测试用例难写？来试试 Sharness

发布时间：2025-11-05 07:52:41 来源：码上建站 作者：IT科技类资讯

Sharness 是测试一个用 Shell 脚本来编写测试用例的测试框架。本文将详细介绍 Sharness 的用例结构及测试用例的编写格式，以及语法规范和技巧，难写教大家如何使用 Sharness 编写测试用例，试试同时参与过 Git 项目的测试测试用例开发，为其测试框架的用例简洁、高效而折服。难写曾经尝试将 Git 测试用例用于其他项目：《复用 git.git 测试框架》[1]。试试不过从 Git 项目中剥离测试用例框架还是测试挺费事的。

一次偶然的用例机会发现已经有人(Christian Couder：Gitlab 工程师，Git项目的难写领导委员会成员之一)已经将 Git 的测试用例框架剥离出来， 成为独立的试试开源项目 Sharness。

有了 Sharness，测试写测试用例不再是用例苦差事。

一 Sharness 是难写什么?

二 Sharness 测试框架的优点

简洁

如果要在测试用例中创建/初始化一个文件(内容为 “Hello, world.”)， 看看 sharness 实现起来有多么简单：

如果要对某应用(hello-world)的输出和预期的 expect 文件进行比较， 相同则测试用例通过，不同则展示差异。测试用例编写如下：

调试方便

每个测试用例脚本可以单独执行。使用 -v 参数，可以显示详细输出。使用 -d 参数，运行结束后保留用例的临时目录。

可以在要调试的test case后面增加 test_pause 语句，例如：

然后使用 -v 参数运行该脚本，会在 test_pause 语句处中断，进入一个包含 sharness 环境变量的子 Shell 中，目录会切换到测试用例单独的工作区。调试完毕退出 Shell 即返回。

三 Git 项目的测试框架结构

Sharness 源自于 Git 项目的测试用例框架。我们先来看看 Git 项目测试框架的结构。

Git 项目测试相关文件

相关代码参见[2]。

四 Git 测试脚本的格式

以如下测试脚本为例[3]：

(1)在文件头，定义 test_description 变量，提供测试用例的简单说明，通常使用一行文本。本测试用例较为复杂，使用了多行文本进行描述。

(2)包含测试框架代码。

(3)定义全局变量，以及定义要在测试用例中用到的函数封装。

(4)用 test_expect_success 等方法撰写测试用例。

(5)在脚本的结尾，用 test_done 方法结束测试用例。站群服务器

五 Sharness 测试框架结构

Sharness 项目由 Git 项目的测试框架抽象而来，项目地址：

https://github.com/chriscool/sharness

Sharness 测试框架示例

我们对 Sharness 测试框架做了一些小改动：

定制版 Sharness 测试框架示例

六 Sharness 测试用例格式

以如下测试脚本为例[4]：

(1)在文件头，定义 test_description 变量，提供测试用例的简单说明，通常使用一行文本。

(2)包含测试框架代码。

(3)定义全局变量，以及定义要在测试用例中用到的函数封装。

(4)用 test_expect_success 等方法撰写测试用例。

(5)在脚本的结尾，用 test_done 方法结束测试用例。

七 关于 test_expect_success 方法的参数

test_expect_success 可以有两个参数或者三个参数。

当 test_expect_success 方法后面是两个参数时，第一个参数用于描述测试用例， 第二个参数是测试用例要执行的命令。

当 test_expect_success 方法后面是三个参数时，第一个参数是前置条件， 第二个参数用于描述测试用例， 第三个参数是测试用例要执行的命令。

例如如下有三个参数的测试，第一个参数定义了前置条件，在 CYGWIN 等环境， 不执行测试用例。

八 Sharness 语法规范和技巧

使用 && 级联各个命令，确保所有命令都全部执行成功

自定义方法，也要使用 && 级联，确保命令全部执行成功

涉及到目录切换，在子 Shell 中进行，以免影响后续测试用例执行时的工作目录

函数命名要有意义

如下内容是 Junio 在代码评审时，对测试用例中定义的 format_git_output 方法的评审意见。Junio 指出要在给函数命名时，要使用更有意义的名称。

Heredoc 的小技巧

使用 heredoc 创建文本文件，如果其中的脚本要定义和使用变量，要对变量中的 $ 字符进行转移。Junio 给出了一个 heredoc 语法的小技巧，可以无需对 $ 字符转义。

Shell 编程语法规范

Git 项目对于 Shell 编写的测试用例制定了语法规范，例如：

完整语法规范参考[5]。

九 sharness 常见的内置函数

开始一个测试用例。

标记为存在已知问题，执行失败不报错，执行成功则警告该 broken 的用例已经 fixed。

后面的一条命令必须失败。如果后面命令成功，测试失败。

命令以给定返回值结束。

比较两个文件内容，相同成功，不同失败并显示差异。

参数必须是一个文件，且存在。

参数必须是一个目录，且存在。

参数指向的文件内容必须为空。

跨平台的 seq，用户生成数字序列。

测试暂停，进入子 Shell。

测试用例结束。

十 扩展 Sharness

Sharness 提供了扩展功能。用户在 sharness.d 目录中添加以 .sh 结尾的脚本文件，即可对 Sharness 进行扩展。例如：

例如：测试脚本在工作区下创建了一个仓库(git init my.repo)，想要在该仓库下执行 git clean，却忘了进入到 my.repo 子目录再执行，结果导致待测试项目中丢失文件。

如：test_tick 方法，可以设置 GIT_AUTHOR_DATE、GIT_COMMITTER_DATE 等环境变量，确保测试脚本多次运行时提交时间的一致性，进而产生一致的提交ID。

例如 git-repo 项目为了避免工作区逃逸，在 trash directory.* 目录下创建 .repo 文件。

十一 Sharness 在项目中的实战

git-repo 是一个命令行工具，非常适合使用 sharness 测试框架编写测试用例。参见[6]。

对于非命令行工具，或者为了测试内置函数，需要先封装一个或多个 fake app，再调用封装的命令行工具进行测试。例如在为 Git 项目开发 proc-receive 钩子扩展时，先开发一个 fake app[7]。

之后再编写测试，调用 fake app(test-tool proc-receive)，帮助完成测试用例的开发。参见下列提交中的测试用例[8]。

还可以使用一些 Shell 编程技巧，在多个测试文件中复用测试用例。例如如下测试用例在测试 HTTP 协议和本地协议时，复用了同一套测试用例(t5411目录下的测试脚本)[9]。

相关链接

[1]https://www.worldhello.net/2013/10/26/test-gistore-using-git-test-framework.html

[2]https://sourcegraph.com/github.com/git/git@master/-/tree/t

[3]https://github.com/git/git/blob/master/t/t5323-pack-redundant.sh

[4]https://github.com/alibaba/git-repo-go/blob/master/test/t0100-init.sh

[5]https://github.com/git/git/blob/master/Documentation/CodingGuidelines

[6]https://github.com/alibaba/git-repo-go

[7]https://github.com/jiangxin/git/blob/jx/proc-receive-hook/t/helper/test-proc-receive.c

[8]https://github.com/jiangxin/git/commit/9654f5eda1153634ab09ca5c6e490bcabdd57e61

[9]https://github.com/jiangxin/git/blob/jx/proc-receive-hook/t/t5411-proc-receive-hook.sh还分享了 Sharness 的扩展功能和项目实战。

【本文为专栏作者“阿里巴巴官方技术”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章