由 dawei 因为 Bash 脚本通常都是在执行一些与操作系统有关的操作，可能会对运行环境造成一些不可逆的操作，比如修改或者删除文件、升级系统中的软件包等。
所以为了确保 Bash 脚本的安全可靠，在生产环境中部署之前一定需要做好足够的测试以确保其行为符合我们的预期。
如何能够安全可靠的去测试 Bash 脚本呢?有人可能会说我们可以用 Docker 容器。是的，这样做即安全又方便。在容器隔离出来的环境中不用担心脚本会破坏我们的系统，而且也能非常简单的快速重建出一个可用的测试环境。不过呢，请考虑以下的几个常见的场景：
场景一：在执行 Bash 脚本测试前，我们需要需要事先安装好所有在 Bash 脚本中会用到的第三方工具，否则这些测试将会因为命令找不到而执行失败。例如，我们在脚本中使用了 Bazel 这个构建工具。我们必须提前安装并配置好 Bazel，而且不要忘记为了能够正常使用 Bazel 还得需要一个支持使用 Bazel 构建的工程。
场景二：测试结果的稳定性可能取决于脚本中访问的第三方服务的稳定性。比如，我们在脚本中使用 curl 命令从一个网络服务中获取数据，但这个服务有时候可能会访问失败。有可能是因为网络不稳定导致的，也可能是因为这个服务本身不稳定。再或者如果我们需要第三方服务返回不同的数据以便测试脚本的不同分支逻辑，但我们可能很难去修改这个第三方服务的数据。
场景三：Bash 脚本的测试用例的执行时间取决于脚本中使用的命令的执行时间。例如，如果我们中脚本中使用了 Gradle 来构建一个工程，由于不同的工程大小 Gradle 的一个构建可能要执行3分钟或者3个小时。这还只是一个测试用例，如果我们还有20个或者100个测试用例呢?我们是否还能在几秒内获得测试报告呢?
即使使用了容器来执行 Bash 脚本测试，也一样无法避免上面的几个问题。环境的准备过程可能会随着测试用例的增多而变的繁琐，测试用例的稳定性和执行时长取决于第三方命令和服务的稳定性和执行时长，还可能很难做到使用不同数据来覆盖不同的测试场景。
对于测试 Bash 脚本来说，我们真正要验证的是 Bash 脚本的执行逻辑。比如在 Bash 脚本中可能会根据传入的参数来组合出内部所调用的命令的选项和参数，我们要验证的是这些选项和参数确实如我们预期的。至于调用的命令在接受了这些选项和参数后由于什么原因而失败，可能我们并不关心这所有的可能原因。