Answers:
我认为约瑟夫·科恩（Joseph Kern）的监控工具是正确的。典型的TDD周期为：编写失败的新测试，然后更新系统，以使所有现有测试通过。这很容易适应Nagios：添加失败的检查，配置服务器，重新运行所有检查。想一想，有时候我确实做到了。
如果您想成为真正的核心人物，请确保编写脚本来检查服务器配置的每个相关方面。像Nagios这样的监视系统可能与其中某些监视系统无关（例如，您可能没有“监视”您的操作系统版本），但是没有理由您无法适当地进行混搭。
虽然我还不能对Puppet清单进行TDD，但我们确实有一个很好的周期来防止未经测试就将更改投入生产。我们设置了两个人偶，一个是我们的生产人偶，另一个是我们的开发人偶。我们使用Puppet的“环境”来设置以下内容：
我们的应用程序开发人员在虚拟机上工作，这些虚拟机从开发Puppetmaster的“测试”环境中获取其Puppet配置。在开发Puppet清单时，通常会在开发过程中将VM设置为测试客户端，并将其指向我们的个人开发环境。一旦我们对清单感到满意，我们会将其推送到测试环境，在此环境中，应用程序开发人员将获得其VM上的更改-当出现问题时，他们通常会大声抱怨：-)
在我们生产机器的代表性子集上，还有另一个木偶以noop模式运行，并指向测试环境。我们使用它来发现清单的潜在问题，然后将其推入生产阶段。
更改通过后，即它们不会破坏应用程序开发人员的机器，并且不会在生产机器的“空”伪造过程的日志中产生不希望的输出，我们将新清单推送到生产中。我们有一个回滚机制，因此我们可以恢复到较早的版本。
我在一个正在迁移到TDD操作模型的环境中工作。对于某些事情，例如监视脚本，这非常有效。我们使用buildbot来设置测试环境并运行测试。在这种情况下，您将从“旧版代码”的角度处理TDD。在TDD中，“旧版代码”是没有测试的现有代码。因此，第一个测试不会失败，它们定义了正确的（或预期的）操作。
对于许多配置作业，第一步是测试服务是否可以解析配置。许多服务为此提供了一些便利。Nagios具有预检模式，cfagent没有动作，apache，sudo，bind，并且许多其他工具都具有类似的功能。对于配置，这基本上是一小步。
一个示例是，如果对不同的部分使用apache和单独的配置文件，则也可以使用不同的httpd.conf文件包装这些部分，以便在测试计算机上运行，从而对这些部分进行测试。然后，您可以测试测试机器上的Web服务器是否在那里给出了正确的结果。
您遵循相同基本模式的每一步。编写测试，通过测试，重构完成的工作。如上所述，当遵循此路径时，测试可能不会始终以公认的TDD方式失败。
里克
我相信以下链接可能会令人感兴趣
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
在Puppet / Python方面也需要付出一些努力 http://www.devco.net/archives/2010/03/27/infrastructure_testing_with_mcollective_and_cucumber.php