python - 我如何测试织物任务

Question

有没有人设法测试他们的 Fabric 任务？有没有图书馆可以帮助解决这个问题？

我对修补/模拟非常熟悉，但它对 Fabric 非常困难，我还查看了 Fabric 自己的测试套件，不幸的是，这没有用，而且似乎没有任何关于它的主题织物文档。

These是我正在尝试测试的任务......如果可能，我想避免启动虚拟机。

任何帮助表示赞赏，提前致谢

Answer 1

免责声明:在下文中，功能测试与系统测试同义。大多数 Fabric 项目缺乏正式的规范，这使得区分没有实际意义。
此外，我可能会在功能测试和集成测试这两个术语之间随意使用，因为它们之间的界限因任何配置管理软件而变得模糊。

Fabric 的本地功能测试很难(或不可能)

我很确定，如果不启动 VM(您将其作为约束之一)或进行极其广泛的模拟(这将使您的测试套件固有地脆弱)，则无法进行功能测试。

考虑以下简单函数:

def agnostic_install_lsb():
    def install_helper(installer_command):
        ret = run('which %s' % installer_command)
        if ret.return_code == 0:
            sudo('%s install -y lsb-release' % installer_command)
            return True
        return False

    install_commands = ['apt-get', 'yum', 'zypper']
    for cmd in install_commands:
        if install_helper(cmd):
            return True

     return False

如果您有一个调用 agnostic_install_lsb 的任务，如何在本地机器上进行功能测试？

您可以通过模拟对 run 的调用来进行单元测试。 , local和 sudo ，但在更高级别的集成测试方面并不多。
如果您愿意对简单的单元测试感到满意，那么除了 mock 之外，对测试框架的要求并不高。和 nose ，因为您的所有单元测试都在严格控制的条件下运行。

你会如何做模拟

你可以 mock sudo , local , 和 run函数将他们的命令记录到一组 StringIO s 或文件，但是，除非我遗漏了一些聪明的东西，否则您还必须非常小心地模拟它们的返回值。
要继续说明您可能已经知道的事情，您的模拟要么必须了解 Fabric 上下文管理器(困难)，要么必须模拟您使用的所有上下文管理器(仍然很难，但没有那么糟糕) )。

如果你确实想走这条路，我认为构建一个测试类更安全、更容易，该类的设置为所有上下文管理器实例化模拟，run , sudo ，以及您正在使用的 Fabric 的任何其他部分，而不是尝试在每次测试的基础上进行更少量的模拟。
到那时，您将为 Fabric 构建一个有点通用的测试框架，您可能应该在 PyPi 上将其作为...“mabric”共享？

我认为这在大多数情况下没有多大用处，因为您的测试最终关心的是如何完成运行，而不仅仅是运行结束时完成了什么。
将命令切换到 sudo('echo "cthulhu" > /etc/hostname')来自 run('echo "cthulhu" | sudo tee /etc/hostname')不应该破坏测试，并且很难看到如何通过简单的模拟来实现这一点。
这是因为我们已经开始模糊功能测试和单元测试之间的界限，这种基本的模拟是尝试将单元测试方法应用于功能测试。

在 VM 上测试配置管理软件是一种既定做法

我敦促您重新考虑您多么希望避免为您的功能测试启动虚拟机。
这是 Chef 测试普遍接受的做法，它面临着许多相同的挑战。

如果您担心这方面的自动化，Vagrant 在简化从模板创建 VM 方面做得非常好。
我什至听说有很好的 Vagrant/Docker 集成，如果你是 Docker 粉丝的话。
唯一的缺点是，如果你是 VMWare 粉丝，Vagrant 需要 VMWare Workstation ($$$)。
或者，只需免费使用 Vagrant 和 Virtualbox。

如果您在 AWS 等云环境中工作，您甚至可以选择使用与生产服务器相同的基本镜像来启动新的 VM，仅用于进行测试。
当然，一个显着的缺点是这需要花钱。
但是，如果您已经在公共(public)云中运行完整的软件堆栈，那么这并不是您成本的重要组成部分，因为测试服务器在一个月内总共只运行几个小时。

简而言之，有很多方法可以解决在 VM 上进行完整功能测试的问题，这对于其他配置管理软件来说是一种久经考验的技术。

如果不使用 Vagrant(或类似的)，保留一套本地可执行的单元测试

使测试依赖于运行 VM 的一个明显问题是它使开发人员的测试变得困难。
对于针对本地代码版本的迭代测试尤其如此，因为某些项目(例如 Web UI 开发)可能需要。

如果您使用 Vagrant + Virtualbox、Docker(或原始 LXC)或类似的解决方案来测试虚拟化，那么本地测试的成本并不高。
这些解决方案可以在 10 分钟内在廉价的笔记本电脑硬件上启动新的虚拟机。
对于特别快速的迭代，您可以针对同一个 VM 进行多次测试(然后用新的 VM 替换它以进行最终测试)。

但是，如果您在公共(public)云或类似环境中进行虚拟化，在这种环境中对 VM 进行过多测试成本很高，那么您应该将您的测试分为可以在本地运行的广泛单元测试套件，以及需要 VM 的集成或系统测试.
这组单独的测试允许在没有完整测试套件的情况下进行开发，在开发过程中针对单元测试运行。
然后，在合并/发送/签署更改之前，它们应该针对 VM 上的功能测试运行。

最终，没有通过功能测试的任何东西都不应该进入您的代码库，但是您应该尝试为此类单元测试套件实现尽可能接近完整的代码覆盖率。
您可以做的越多来增强单元测试给您的信心，效果就越好，因为它减少了系统测试的虚假(并且可能代价高昂)运行的次数。