在我上一个项目中,我们的fabfile失控了。虽然我们项目的其余部分经过了充分测试,但我们没有为fabfile编写单个测试。重构是可怕的,在我们运行命令之前,我们不相信结构命令会如何工作。
我正在开始一个新项目,我想确保我们的fabfile从一开始就经过充分测试。服从测试山羊有一个great article讨论一些可能的策略,但它有更多的问题而不是答案。使用fabtest是可能的,虽然它似乎已经死了。
有没有人成功测试过他们的fabfile?如果是这样,怎么样?
答案 0 :(得分:2)
在Docker实例
使用docker diff验证是否更改了正确的文件 Fabfile。
这仍然是相当多的工作,但它允许在没有过多Fabfile修改的情况下进行测试。
答案 1 :(得分:1)
你试过python-vagrant吗?它似乎与fabtest做同样的事情,但它包括一些Fabric演示,仍然使用和维护。
答案 2 :(得分:1)
幻灯片 - mentioned by Henrik Andersson - 从当时可用here
RobinKåvelandHansen回复我:
为了保持我们的结构代码在那里得到充分测试,我们做了一些重构类型的例子。
总的来说,我会说最好的建议是尝试避免在更高级别的代码中使用shell命令等低级代码来决定运行什么代码,例如。从做出决策的代码中分离出效果完整的代码。
分支增加了您需要的测试用例的数量,并且为在某些服务器上更改状态的代码编写好的测试用例需要付出更多的努力。
当时,我们使用mock来模拟结构,为在服务器上产生副作用的无分支代码编写测试用例,因此代码+测试看起来很像this
显然这有一个弱点,它不会在shell命令本身中发现错误。我的经验是,这很少是导致严重问题的原因。使用mock的其他选项是使用以下想法来运行 在您的计算机上进行本地测试,而不是remotely
也许最强大的方法是在流浪汉中运行测试,但这样做的缺点是需要大量设置并且倾向于使测试更慢。
我认为进行快速测试非常重要,因为这样你就可以一直运行它们,它们会给你一个非常好的反馈循环。我为当前雇主编写的部署脚本有大约150个测试用例并且运行时间不到0.5秒,因此部署脚本实际上会在部署之前进行自检。 这确保了它在每个开发人员机器上都经过测试,这已经发现了一些好的错误,例如linux和mac osx行为不同的情况。