在“盐堆栈”中，这些位称为状态。如果状态与现实不符，该工具将为我们解决。换句话说-我们正在为基础架构编写测试，如果测试失败，该工具将自行修复。至少这是个主意。
XP教我们使用TDD，问题是它是否适用于基础架构？工具提示确实如此。
我可以想象几种非常有用的测试类型。
我们编写了与已部署服务捆绑在一起的冒烟测试，以确保端到端已部署服务正常运行。这将是一个API调用或/和systemctl检查，以确保我们刚刚部署的内容能够正常工作。由于ansible之类的工具具有确保服务正在运行的状态，因此许多功能都可以在相同的状态下使用。针对docker或其他临时虚拟化引擎。这迫使角色分离，并允许在处理角色时将其与剧本分开执行。测试通常允许模拟该角色应该使用的变量。不过，其他示例似乎是ansible引擎的副本（声明文件属于用户...）。
ThoughtWorks技术雷达现在赞扬诸如inspec，serverspec或goss之类的工具来验证服务器符合规格。但是我们正在编写规范，不是吗？
如果我们以状态/角色描述基础架构，那么进一步测试基础架构是否有意义？我怀疑在一个团队提供规格并遵循其他要求的大型组织中，这是否变得更加必要，或者如果有大量角色，您可能想运行其中一部分并从测试中获得快速收益？我正在努力了解如果您对相同的问题有一个角色/状态，为什么还要编写测试。
#1 楼
简而言之，我看到针对您的基础架构的两类测试：1）它具有运行应用程序所需的一切，2）它没有任何多余的东西。首先，您可以将实际软件的测试套件视为基础架构的一种“元测试”。只要您为每个测试运行从头创建基础架构，并且测试套件完全在该基础架构上运行（即，不使用外部服务），那么整个套件都是绿色的事实意味着您所编写的基础架构也已足够第二，尤其是从安全角度来看，您可以针对基础结构编写测试。也就是说，如果您的基础架构的一部分是运行Linux的VM，则可以编写一个针对该VM进行端口扫描的测试，以确保没有意外打开的端口，这可能是由意外
apt-get install端安装的-影响。或者，您可以编写测试来检查在适当的测试套件完成后是否更改了任何意外文件。或者，您可以检查您的VM或Docker容器的ps输出中是否存在意外进程等，构建白名单等，从而在某些第三方软件包在某些升级中以未记录的方式（或未引起注意的方式）更改时得到自动通知。 br /> 从某种意义上说，这第二种测试类似于您在经典操作设置中所做的测试，即加固服务器并检查入侵情况，避免使用全部资源等。 >
#2 楼
恕我直言，为IaaC状态规范完全涵盖的项目编写TDD测试是相当多余的。这样做意味着IaaC的有效性值得怀疑-为什么要使用它呢？从另一个预期的IaaC本身（如果/如果正确完成的话）来看，它结合了已经测试和考虑过的功能可靠地运作。这使它具有吸引力，并使编写TDD匹配测试变得多余。例如，一个指定安装了SSH的系统的IaaC配置已经包含了对正确安装SSH的可靠检查，如果没有，正确安装它的机制。这将进行TDD测试，以检查SSH是否冗余安装。如果您的IaaC配置还指定了要启动sshd并在特定端口上侦听，则针对sshd运行和侦听相应端口的TDD测试也将是多余的。
请注意，我的答案不是针对TDD或检查您的IaaC配置整体是否符合特定目的的任何其他类型的测试。这仍然有效，并且可以在制定该IaaC规范的过程中用于TDD，CI或类似检查中-我相信@AnoE的答案适用于这种情况。
评论
您是否采用相同的想法来确保从外部配置文件中解析的特定自定义端口上启用了SSH（或其他任何功能）？这不是基于测试的单元，而是新颖的逻辑。
–乔·劳里森（Jon Lauridsen）
17 Dec 4'在18:28
如果支持的话，它应该是IaaC的一部分。如果不是，则此讨论实际上不适用。是的，这可能会滑入IaaC可以涵盖的范围，但这是一个不同的讨论。
–丹·科尼莱斯库（Dan Cornilescu）
17年4月4日在19:06
我还假设我们不在需要冗余检查的环境中-在某些情况下，可能需要遵循完全不同的代码路径甚至基础结构的冗余检查。
–丹·科尼莱斯库（Dan Cornilescu）
17年4月4日在19:08
#3 楼
看起来这里的每个人都假设IAC工具始终能够按预期运行，但是我可以（根据我自己的经验）知道情况并非总是如此，否则单元测试实际上是无用的。我记得上面写着“ Ansible Playbook跑了，一切都很好”的图片，背景中有一座建筑物在燃烧...
运行声明式状态并使服务器处于此实际声明状态与我的观点有两点不同至少要查看和体验。
广泛的异构环境，分布在多个DC上，可以通过公共网络访问...等等。有多个原因导致无法完全或部分应用状态。 。
由于所有这些原因，单元测试仍有空间，可以让人们获取服务器实际状态的快照，这又可能与目标状态有所不同。
因此，我想说是的，即使在IAC托管环境中，单元测试也很有用。
编辑
IaC代码库的dev分支的非回归端如何？所以您会在dev分支中对代码进行更改，然后将其合并到prod分支中，希望不会破坏所有内容？单元测试是如此有价值，并且通常很容易实现，我不明白为什么没有这种功能的人会编写代码。
参考（对此表示歉意）：https://fr.slideshare.net/ logilab / testinfra-pyconfr-2017
评论
至少有礼貌地添加一些反对意见，你不认为反对投票人吗？尤其是在这样的问题上，辩论可能会非常有益，甚至具有建设性。
–码头
18年3月22日在14:18
我认为您的回答语气对与这个问题有互动的每个人都具有攻击性，而且您没有以自己的榜样提供任何参考，也没有描述任何观察到的故障是拒绝投票的原因。您最终会说出与其他答案相同的话，在置备系统中进行烟雾测试，以确保系统正常运行，大多数系统都会因无法将系统收敛到所需状态而失败。关于您的编辑，通常合并是在部署到暂存并确保冒烟测试通过之后进行的。
–滕西拜
18年3月22日在15:12
我绝对不打算变得好斗，我这里没有使用我的natibve语言（我想这很明显:)）。
–码头
18 Mar 22 '18在15:26
如果您愿意，我们可以在DevOps Chat中讨论它，我想几年前在devoxx活动上我看到了这个演示文稿或类似的演示文稿。我稍微不同意调用该单元测试，这是更多的功能测试。
–滕西拜
18年3月22日在16:00
我的开发团队中的一些人告诉我，这完全不是单元测试，我不是开发人员，所以我称这个单元测试可能是错误的
–码头
18年3月22日在17:16
#4 楼
以我的经验，Dev和Ops之间的主要区别之一是“繁重的运行时依赖性”。安装软件包在很大程度上取决于存储库，网络或有效密钥，或者说实例化一个新的云服务器-这取决于您的提供程序资源。就服务器配置而言，即使您未更改其设置代码，您的图片在大多数情况下都会有效，但有时无效。因此，我认为测试对于提供有效的图像确实至关重要。包括DNS解析，路由和防火墙？即使您的IaaC提供程序API可以按预期工作（我在该区域中看到过有线问题），但在这种情况下我还是很喜欢TDD。
因为在该区域中没有找到任何测试工具，我们在我们的业余时间写了一个：
https://github.com/DomainDrivenArchitecture/dda-serverspec-crate
所以我认为TDD在DevOps世界中确实很重要！ >
评论
所以过了一段时间，这正是我的立场。由ansible执行的部分不会自己进行测试，但是这些动作的副作用是使用goss测试的。因此，例如，安装（可安装）RPM，然后测试是否放置了预期的默认文件，或者服务正在运行并正在侦听特定端口。我不想自动解决此问题，但会收到通知并停止进度。当然，Ansible也可以为您测试系统，您只需要对其进行明确说明即可，但是在我们的案例中，我们使用goss来测试容器内服务的行为
–JackLeo
18年5月18日在11:32