基础设施部署的测试驱动开发？

我认为您不能使用测试驱动开发。但是您当然可以尝试在新服务器上进行单元测试。

基本上，您需要部署服务器，以测试模式启动服务，然后从另一台服务器（或一系列服务器）针对服务运行测试。然后最终将它们投入生产。

也许使用 python 脚本连接到数据库、网页和 ssh 服务。然后返回 PASS/FAIL。对你来说将是一个好的开始。

或者你可以把它整合到一个监控解决方案中，比如 Zenoss、Nagios 或 Munin。然后您可以在部署期间进行测试；并在生产过程中进行监控。

我认为 Joseph Kern 使用监控工具走在正确的轨道上。典型的 TDD 循环是：编写一个失败的新测试，然后更新系统以使所有现有测试通过。这很容易适应 Nagios：添加失败的检查，配置服务器，重新运行所有检查。想一想，我有时就是这样做的。

如果您想获得真正的核心，您将确保编写脚本来检查服务器配置的每个相关方面。像 Nagios 这样的监控系统可能与其中一些无关（例如，您可能不会“监控”您的操作系统版本），但没有理由不能适当地混合搭配。

虽然我还不能用 Puppet 清单做 TDD，但我们确实有一个很好的循环来防止未经测试的更改进入生产。我们设置了两个 puppetmaster，一个是我们的生产 puppetmaster，另一个是我们的开发 puppetmaster。我们使用 Puppet 的“环境”来设置以下内容：

• 开发环境（每个处理 Puppet 清单的人一个）
• 测试环境
• 生产环境

我们的应用程序开发人员在虚拟机上工作，这些虚拟机从开发 Puppetmaster 的“测试”环境中获取他们的 Puppet 配置。我们在开发 Puppet manifest 时，通常会在开发过程中设置一个 VM 作为测试客户端，并将其指向我们个人的开发环境。一旦我们对清单感到满意，我们就会将它们推送到测试环境，应用程序开发人员将在他们的虚拟机上获得更改 - 他们通常会在出现问题时大声抱怨:-)

在我们生产机器的一个有代表性的子集上，有第二个 puppetd ​​在 noop 模式下运行并指向测试环境。我们使用它来在清单被推送到生产之前发现它们的潜在问题。

一旦更改通过，即它们不会破坏应用程序开发人员的机器，并且它们不会在生产机器的“noop”puppetd ​​进程的日志中产生不良输出，我们会将新清单推送到生产中。我们有一个回滚机制，因此我们可以恢复到早期版本。

我在一个正在迁移到 TDD 操作模型的环境中工作。对于监视脚本之类的某些事情，这非常有效。我们使用 buildbot 来设置测试环境并运行测试。在这种情况下，您从“遗留代码”的角度来处理 TDD。在 TDD 中，“遗留代码”是没有测试的现有代码。所以第一个测试不会失败，它们定义了正确的（或预期的）操作。

对于许多配置作业，第一步是测试配置是否可以被服务解析。许多服务提供了一些设施来做到这一点。Nagios 有 preflight 模式，cfagent 没有 act，apache、sudo、bind 和许多其他有类似的设施。这基本上是配置的 lint 运行。

一个例子是，如果您使用 apache 并为不同的部分使用单独的配置文件，您也可以测试这些部分，只需使用不同的 httpd.conf 文件来包装它们以在您的测试机器上运行。然后您可以测试测试机器上的网络服务器是否在那里给出正确的结果。

沿途的每一步都遵循相同的基本模式。编写测试，使测试通过，重构你所做的工作。如上所述，当遵循这条路径时，测试可能并不总是以公认的 TDD 方式失败。

里克

我相信以下链接可能会引起您的兴趣

1. cucumber-nagios - 让您将Cucumber套件转换为 Nagios 插件的项目，并附带 SSH、DNS、Ping、AMQP 和通用“执行命令”类型任务的步骤定义
   http://auxesis.github.com/cucumber- nagios/
   http://www.slideshare.net/auxesis/behaviour-driven-monitoring-with-cucumbernagios-2444224
   http://agilesysadmin.net/cucumber-nagios

2. 在 Puppet/Python 方面也有一些努力 http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php