Fabric：如何对我的fabfile进行单元测试？

Question

在我之前做的一个项目中，我们的fabfile变得有些失控。虽然项目的其他部分测试得很好，但我们却没有为fabfile写过一个测试。重构代码让人感到害怕，我们在运行命令之前根本不敢相信这个fabric命令会按照我们的预期工作。

现在我开始了一个新项目，我想确保我们的fabfile从一开始就经过良好的测试。Obey the Testing Goat网站上有一篇很棒的文章，讨论了一些可能的策略，但问题多于答案。使用fabtest也是一种选择，尽管它似乎已经不再维护了。

有没有人成功地对他们的fabfile进行了单元测试？如果有，是怎么做到的？

Answer 1

Henrik Andersson提到的幻灯片可以在这里找到。

Robin Kåveland Hansen给我回复说：

我们在保持fabric代码良好测试方面做了一些重构的例子。

一般来说，我的建议是尽量避免在高层代码中使用低层代码，比如在做决策时使用shell命令。也就是说，要把有影响的代码和做决策的代码分开。

分支会增加你需要的测试案例数量，而且为那些在服务器上改变状态的代码写好的测试案例会花费更多的精力。

当时，我们使用mock来模拟fabric，以便为没有分支的、对服务器有副作用的代码编写测试案例，所以代码和测试看起来很像这个。
显然，这样的做法有个缺点，就是无法发现shell命令本身的bug。不过我个人的经验是，这种情况很少导致严重问题。

使用mock的其他选择是，可以考虑在本地机器上运行测试，而不是远程运行。

也许最稳妥的方法是在vagrant中运行测试，但这需要很多设置，并且测试速度可能会变慢。
我认为快速的测试很重要，因为这样你可以随时运行它们，并且它们能给你提供很好的反馈。

我为现在的雇主写的部署脚本有大约150个测试案例，并且运行时间不到0.5秒，所以这个部署脚本在部署之前会进行自我测试。
这确保了它在每个开发者的机器上都能被测试，这样就能发现一些bug，比如Linux和Mac OS X在某些情况下的表现不同。

Answer 2

你有没有试过 python-vagrant 呢？它看起来和 fabtest 做的事情差不多，不过它还包含了一些 Fabric 的示例，而且现在还在使用和维护中。

Answer 3

1. 在一个Docker 实例中运行你的 Fabfile 任务。

2. 使用 docker diff 来确认 Fabfile 修改了正确的文件。

这虽然还是需要做不少工作，但可以在不频繁修改 Fabfile 的情况下进行测试。