<story><title>Open sourcing Terratest: tools for testing infrastructure code</title><url>https://blog.gruntwork.io/open-sourcing-terratest-a-swiss-army-knife-for-testing-infrastructure-code-5d883336fcd5</url></story><parent_chain></parent_chain><comment><author>brikis98</author><text>I&amp;#x27;m one of the creators of Terratest. Happy to answer questions.&lt;p&gt;The main question I&amp;#x27;ve seen so far seems to be how Terratest compares with various &amp;quot;spec&amp;quot; tools (e.g., inspec, serverspec). Most of the spec tools focus on checking the properties of a single server or resource. For example, is httpd installed and running? Terratest is largely for end-to-end, acceptance style testing, where you deploy your real infrastructure, in a real environment (e.g., AWS), and test the infrastructure actually works as expected.&lt;p&gt;For example, let&amp;#x27;s say you wanted to test a module for running Vault (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;hashicorp&amp;#x2F;terraform-aws-vault&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;hashicorp&amp;#x2F;terraform-aws-vault&lt;/a&gt;), which is a distributed secret store. With a spec tool, you might test a single Vault node to check that Vault is installed and the process is running. With Terratest, you&amp;#x27;d check that the whole Vault cluster deployed correctly, bootstrapped itself (including auto-discovery of the other nodes), that you can initialize the cluster, unseal it store data, retrieve data, and so on.</text></comment>
<story><title>Open sourcing Terratest: tools for testing infrastructure code</title><url>https://blog.gruntwork.io/open-sourcing-terratest-a-swiss-army-knife-for-testing-infrastructure-code-5d883336fcd5</url></story><parent_chain></parent_chain><comment><author>peterwwillis</author><text>It&amp;#x27;s weird to think of infrastructure&amp;#x2F;deploy automation in terms of &amp;quot;testing&amp;quot;. Yes, you are always testing things, but not always in the &amp;quot;func test&amp;quot; sort of way. There&amp;#x27;s automation testing, and there&amp;#x27;s testing of automation, and there&amp;#x27;s tests that are part of automation. Terratest seems to be the second, but it&amp;#x27;s the third one I think is most useful.&lt;p&gt;If you build your infrastructure&amp;#x2F;deploy automation correctly, you should be able to redeploy your full stack all the time, and when it succeeds, throw traffic at it, and if you don&amp;#x27;t detect any anomalies, make that the new production service. On the detection of anomalies you simply move the traffic back to the previously deployed incarnation (or re-deploy the old incarnation, if necessary). For sufficiently large systems this gets more complicated as you can&amp;#x27;t just duplicate your resources, but the smaller pieces that have actually changed can be shifted around.&lt;p&gt;The idea of a &amp;quot;rollback&amp;quot; is really just &amp;quot;return to a previously known good state&amp;quot;, but it&amp;#x27;s misleading. It was previously good &lt;i&gt;before now&lt;/i&gt;. Now things have changed, and it might not still be good. So just as much as you can test newly deployed changes before you make it the production service, you should probably also test the &lt;i&gt;previously deployed changes&lt;/i&gt; to make sure they will work again if pressed back into service. So, regression testing for infrastructure, I guess. (You&amp;#x27;d do this if you were building a physical product like a network appliance to make sure your old appliances still work with newer software releases, but we rarely think of software-derived infrastructure this way)</text></comment>