Upgrade to Pro — share decks privately, control downloads, hide ads and more …

End To End Testing with Terratest

tiemma
April 30, 2020

End To End Testing with Terratest

Anyone ever tested their IAC before?!, guessing no.

This talk features guidelines on how to test your Terraform code with Terratest from the start to finish to ensure those itchy state changes on your next deployment don't cause hours of heartbreaking debugging on your cloud or on-prem systems.

tiemma

April 30, 2020
Tweet

More Decks by tiemma

Other Decks in Programming

Transcript

  1. Bakare Emmanuel Bakman ! Experienced Plumber @ DEIMOS fixing pipelines

    and other stuff Failing comedian in real life
  2. Then one day we write a couple tests But they

    fail or we hack it for that prod deployment...
  3. Configurations aren’t always constant 1 != “1” dev And it

    doesn’t get easier with multiple environments 2 != “1” prod 3 != “12” staging
  4. Terratest Infrastructure testing library in Golang Terratest is a testing

    library with a set of useful modules that help make sure your infrastructure code doesn’t suck and stop working half way in production. Just like software, just because it compiles does not mean it is working. Terratest helps make sure it works. Check out the list of their supported libraries on their site: https://terratest.gruntwork.io/
  5. Guidelines Modules are your starting point, don’t write a 200

    line main.tf file Resources are first class citizens like variables, you don’t test variables so why test single resources with constant parameters. You’d also have duplicate resources to test different use cases, it gets longer and longer.
  6. Guidelines Unit tests should cover parts of your infrastructure that

    can be singly created Things like instances, AMI packages etc. Unit test the individual components that make your infrastructure.
  7. Guidelines Do not hard code your configuration like you did

    with your variables.tf Tests do not work the same as a deploy. Randomize your configuration, deploy in a different region without resources. Literally set yourself up for failure and see how it responds. If it passes when it should not, I’d check production if I were not testing before.
  8. Guidelines Using your staging to run tests is like driving

    a driverless car, you’re not always in control Isolate your environments for testing, spin up new accounts and tear it down. Some tests leave resources but you can use tools like cloudnuke from gruntwork to delete other resources. Just imagine doing a cloudnuke on prod by “accident”, tragic!
  9. Guidelines Don’t reuse state, implementing state locking should not be

    a go to plan for tests When testing, run all your configs as though you got a budding new server with that extra “vroom”. Adding in state to it just brings all the problems your tests tried to avoid.
  10. Guidelines Keep it small but keep it reasonable Things like

    security audits, benchmarks, networking checks etc. Depending on how far your scale grows, you’d want to be sure you’ve got all these covered during your builds.
  11. Tests don’t really catch all your errors, eventual consistency does

    become inconsistent but it keeps the bugs away