问题描述
在使用基础设施即代码（Infrastructure as Code，IaC）时，对于是否适用测试驱动开发（Test-Driven Development，TDD）存在疑问。用户提到了一些工具，如ansible、chef、puppet、salt stack等，这些工具推动我们编写基础设施的描述，并解决差异。用户还提到了一些测试的类型，例如端到端的烟雾测试和验证服务器是否符合规范的测试。用户想知道在描述基础设施的状态/角色的情况下，是否有必要进一步测试基础设施。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
TDD与基础设施即代码
在基础设施即代码中，我们可以将测试分为两个类别：1）确保基础设施具备运行应用程序所需的一切；2）确保基础设施没有任何多余的东西。
首先，您可以将实际软件的测试套件视为对基础设施的“元测试”。只要每次测试运行时都从头开始创建基础设施，并且测试套件完全在该基础设施上运行（即不使用外部服务），整个测试套件都通过意味着您的基础设施也是足够的。
其次，特别是从安全性的角度来看，您可以针对基础设施编写测试。例如，如果基础设施的一部分是运行Linux的虚拟机，您可以编写一个端口扫描测试，以确保没有意外打开的端口，这些端口可能是由意外的apt-get install副作用安装的。或者您可以编写检查在您的正确测试套件完成后是否更改了任何意外文件的测试。或者您可以检查VM或Docker容器的ps输出是否有意外的进程等，构建白名单等，并在某些升级中自动通知您某些第三方软件包以未记录（或未注意到）的方式进行了更改。
这些第二类测试在某种程度上与您在经典的运维环境中所做的事情类似，即加固服务器并检查入侵，避免资源耗尽等。
TDD与基础设施的测试
在基础设施即代码中，我们可以将测试分为两个类别：1）确保基础设施具备运行应用程序所需的一切；2）确保基础设施没有任何多余的东西。
首先，您可以将实际软件的测试套件视为对基础设施的“元测试”。只要每次测试运行时都从头开始创建基础设施，并且测试套件完全在该基础设施上运行（即不使用外部服务），整个测试套件都通过意味着您的基础设施也是足够的。
其次，特别是从安全性的角度来看，您可以针对基础设施编写测试。例如，如果基础设施的一部分是运行Linux的虚拟机，您可以编写一个端口扫描测试，以确保没有意外打开的端口，这些端口可能是由意外的apt-get install副作用安装的。或者您可以编写检查在您的正确测试套件完成后是否更改了任何意外文件的测试。或者您可以检查VM或Docker容器的ps输出是否有意外的进程等，构建白名单等，并在某些升级中自动通知您某些第三方软件包以未记录（或未注意到）的方式进行了更改。
这些第二类测试在某种程度上与您在经典的运维环境中所做的事情类似，即加固服务器并检查入侵，避免资源耗尽等。
TDD与基础设施即代码的结合
在基础设施即代码中，TDD测试对于提供可靠的工作镜像非常重要。尤其是在涉及到多个数据中心、通过公共网络访问等的广泛和异构的环境中，测试对于提供可靠的工作镜像至关重要。例如，您可以测试整个网络设置的可达性，包括DNS解析、路由和防火墙。即使您的IaC提供程序的API按预期工作（我在这个领域遇到过一些奇怪的问题），我仍然喜欢TDD。
由于在这个领域中没有找到任何测试工具，我们在业余时间编写了一个工具：dda-serverspec-crate。因此，我认为在DevOps世界中，TDD非常重要。