6

我正在对一些遗留的shell 脚本进行单元测试。

在现实世界中，脚本通常用于调用实用程序，如find、tar、cpio、grep、sed、等rsync，date其中包含一些包含很多选项的相当复杂的命令行。有时会构造和使用正则表达式或通配符模式。

一个例子：通常由 cron 定期调用的 shell 脚本的任务是使用实用程序rsync将一些巨大的目录树从一台计算机镜像到另一台计算机。应该从镜像过程中排除几种类型的文件和目录：

  #!/usr/bin/env bash
  ...
  function mirror() {
      ...
      COMMAND="rsync -aH$VERBOSE$DRY $PROGRESS $DELETE $OTHER_OPTIONS \
                   $EXCLUDE_OPTIONS $SOURCE_HOST:$DIRECTORY $TARGET"
      ...
      if eval $COMMAND
      then ...
      else ...
      fi
      ...
  }
  ...

正如 Michael Feathers 在他著名的著作《有效地使用遗留代码》中所写，一个好的单元测试运行速度非常快，并且不会触及网络、文件系统或打开任何数据库。

按照 Michael Feathers 的建议，这里使用的技术是：依赖注入。这里要替换的对象是实用程序rsync。

我的第一个想法：在我的 shell 脚本测试框架（我使用bats）中，我$PATH以找到模型 rsync而不是真正的rsync实用程序的方式进行操作。这个模型对象可以检查提供的命令行参数和选项。与被测脚本的这一部分中使用的其他实用程序类似。

我过去在脚本编写领域遇到的实际问题通常是由文件或目录名称中的特殊字符、引用或编码问题、缺少 ssh 密钥、错误权限等引起的错误。这种类型的错误将逃脱这种单元测试技术。（我知道：对于其中一些问题，单元测试根本无法解决问题）。

另一个缺点是为像or这样的复杂实用程序编写模型容易出错，并且本身就是一项繁琐的工程任务。rsyncfind

我相信上面描述的情况很普遍，其他人可能也遇到过类似的问题。谁有一些聪明的想法并愿意在这里与我分享？

4

2 回答 2

3

您可以使用函数模拟任何命令，如下所示：

function rsync() {
    # mock things here if necessary
}

然后导出函数并运行单元测试：

export -f rsync
unittest
于 2016-09-29T14:09:19.327 回答
2

嘉吉的困境：

“任何设计问题都可以通过增加额外的间接级别来解决，除了太多的间接级别。”

为什么要模拟系统命令？毕竟，如果您正在编程 Bash，系统是您的目标，您应该使用该系统评估您的脚本。

顾名思义，单元测试将使您对正在设计的系统的单一部分充满信心。因此，对于 bash 脚本，您必须定义您的单位。一个函数？脚本文件？命令？

鉴于您想将单位定义为函数，我建议您编写上面列出的众所周知的错误列表：

  • 文件或目录名称中的特殊字符
  • 引用或编码问题
  • 缺少 ssh 密钥
  • 权限错误等等。

并为它编写一个测试用例。并尽量不要偏离系统命令，因为它们是您交付的系统的组成部分。

于 2016-09-29T13:54:00.477 回答