Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento fornece diretrizes e recomendações para testar módulos e configurações do Terraform para Google Cloud.
Às vezes, testar módulos e configurações do Terraform segue padrões e convenções diferentes do teste de código do aplicativo. Embora o teste do código do aplicativo envolva principalmente o teste da lógica de negócios dos próprios aplicativos, o teste completo do código da infraestrutura requer a implantação de recursos reais da nuvem para minimizar o risco de falhas de produção. Há algumas considerações ao executar testes do Terraform:
A execução de um teste do Terraform cria, modifica e destrói a infraestrutura
real. Portanto, os testes podem ser demorados e caros.
Não é possível realizar somente um teste de unidade em uma arquitetura de ponta a ponta. A melhor
abordagem é dividir a arquitetura em módulos e testá-los
individualmente. Os benefícios dessa abordagem incluem desenvolvimento iterativo mais rápido devido ao tempo de execução mais rápido, custos reduzidos para cada teste e chances reduzidas de falhas de teste devido a fatores além do seu controle.
Evite reutilizar o estado, se possível. Pode haver situações em que você
está fazendo testes com configurações que compartilham dados com outras configurações,
mas o ideal é que cada teste seja independente e não reutilize o estado
deles.
Use métodos de teste mais baratos primeiro
Há vários métodos que você pode usar para testar o Terraform. Em ordem crescente
de custo, tempo de execução e profundidade, eles incluem o seguinte:
Análise estática:teste a sintaxe e a estrutura da configuração
sem implantar recursos usando ferramentas como compiladores, lints
e simulações. Para fazer isso, use
terraform validate.
Teste de integração do módulo: para garantir que os módulos funcionem corretamente, teste
os módulos individuais isoladamente. O teste de integração de módulos envolve a implantação do módulo em um ambiente de teste e a verificação de que os recursos esperados foram criados. Há vários frameworks de teste que
facilitam a criação de testes da seguinte maneira:
Teste de ponta a ponta:ao estender a abordagem de teste de integração a
um ambiente inteiro, você pode confirmar se vários módulos funcionam juntos.
Nessa abordagem, implante todos os módulos que compõem a arquitetura em um
ambiente de teste atualizado. O ideal é que o ambiente de teste seja o mais semelhante possível ao ambiente de produção. Isso é caro, mas oferece a
maior confiança de que as alterações não afetam seu ambiente de produção.
Comece aos poucos
Certifique-se de que seus testes são criados iterativamente uns nos outros. Recomendamos executar testes menores primeiro e, em seguida, passar para testes mais complexos usando uma abordagem falha rápida.
Ordem aleatória de IDs de projetos e nomes de recursos
Para evitar conflitos de nomenclatura, verifique se as configurações têm um ID do projeto globalmente exclusivo e nomes de recursos não sobrepostos em cada projeto. Para fazer isso, use namespaces nos seus recursos. O Terraform tem um
provedor aleatório
integrado para isso.
Usar um ambiente separado para testar
Durante os testes, muitos recursos são criados e excluídos. Verifique se o
ambiente está isolado dos projetos de desenvolvimento ou produção para evitar
exclusões acidentais durante a limpeza de recursos. A melhor abordagem é fazer com que cada
teste crie um novo projeto ou pasta. Para evitar configurações incorretas, considere
criar contas de serviço especificamente para cada execução de teste.
Limpar todos os recursos
O teste do código da infraestrutura significa que você está implantando recursos reais.
Para evitar cobranças, implemente uma etapa de limpeza.
Para destruir todos os objetos remotos gerenciados por uma configuração específica, use o comando terraform destroy. Alguns frameworks de teste têm uma etapa de limpeza
integrada para você. Por exemplo, se você estiver usando o Terratest, adicione defer terraform.Destroy(t, terraformOptions) ao teste. Se você estiver usando
Kitchen-Terraform, exclua seu espaço de trabalho usando
terraform kitchen delete WORKSPACE_NAME.
Depois de executar o comando terraform destroy, execute também procedimentos de limpeza adicionais para remover todos os recursos que o Terraform não conseguiu destruir. Para fazer isso, exclua todos os projetos usados para execução do teste ou use uma ferramenta como o módulo project_cleanup.
Otimizar o tempo de execução do teste
Para otimizar o tempo de execução do teste, use as seguintes abordagens:
Executar testes em paralelo. Alguns frameworks de teste são compatíveis com a execução
de vários testes do Terraform simultaneamente.
Por exemplo, com o Terratest, é possível fazer isso adicionando
t.Parallel() após a definição da função de teste.
Teste em etapas. Separe seus testes em configurações independentes que possam ser testadas separadamente. Essa abordagem elimina a necessidade de passar por todos os estágios ao executar um teste e acelera o ciclo de desenvolvimento iterativo.
Por exemplo, no Kitchen-Terraform, divida testes em
pacotes separados. Ao iterar, execute cada pacote de forma independente.
Da mesma forma, usando o Terratest, envolva cada estágio do teste com stage(t, STAGE_NAME, CORRESPONDING_TESTFUNCTION).
Defina variáveis de ambiente que indicam quais testes serão executados. Exemplo,
SKIPSTAGE_NAME="true".
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2024-12-22 UTC."],[[["\u003cp\u003eTesting Terraform requires deploying real cloud resources, which can be time-consuming and costly, therefore it's recommended to break down architectures into smaller modules for individual testing.\u003c/p\u003e\n"],["\u003cp\u003eStart with less expensive testing methods like static analysis and module integration testing before moving to end-to-end testing, using a fail-fast approach to catch errors quickly.\u003c/p\u003e\n"],["\u003cp\u003eUtilize unique project IDs and resource names, employing the Terraform random provider to avoid conflicts, and use isolated test environments separate from development or production.\u003c/p\u003e\n"],["\u003cp\u003eImplement cleanup procedures, including \u003ccode\u003eterraform destroy\u003c/code\u003e and other tools, to remove all resources created during testing to avoid unnecessary costs.\u003c/p\u003e\n"],["\u003cp\u003eOptimize test runtime by running tests in parallel and separating tests into stages for faster iteration, using frameworks like Terratest or Kitchen-Terraform for efficient test management.\u003c/p\u003e\n"]]],[],null,["# Best practices for testing\n\nThis document provides guidelines and recommendations for testing\nTerraform for Google Cloud modules and configurations.\n\nTesting Terraform modules and configurations sometimes follows different\npatterns and conventions from testing application code. While testing\napplication code primarily involves testing the business logic of applications\nthemselves, fully testing infrastructure code requires deploying real cloud\nresources to minimize the risk of production failures. There are a few\nconsiderations when running Terraform tests:\n\n- Running a Terraform test creates, modifies, and destroys real infrastructure, so your tests can potentially be time-consuming and expensive.\n- *You cannot purely unit test an end-to-end architecture*. The best approach is to break up your architecture into modules and test those individually. The benefits of this approach include faster iterative development due to faster test runtime, reduced costs for each test, and reduced chances of test failures from factors beyond your control.\n- *Avoid reusing state if possible*. There may be situations where you are testing with configurations that share data with other configurations, but ideally each test should be independent and should not reuse state across tests.\n\nUse less expensive test methods first\n-------------------------------------\n\nThere are multiple methods that you can use to test Terraform. In ascending\norder of cost, run time, and depth, they include the following:\n\n- **Static analysis:** Testing the syntax and structure of your configuration without deploying any resources, using tools such as compilers, linters, and dry runs. To do so, use [`terraform validate`](https://www.terraform.io/cli/commands/validate)\n- **Module integration testing** : To ensure that modules work correctly, test individual modules in isolation. Integration testing for modules involves deploying the module into a test environment and verifying that expected resources are created. There are several testing frameworks that make it easier to write tests, as follows:\n - [Google's blueprint testing framework](https://pkg.go.dev/github.com/GoogleCloudPlatform/cloud-foundation-toolkit/infra/blueprint-test)\n - [Terratest](https://terratest.gruntwork.io/)\n - [Kitchen-Terraform](https://newcontext-oss.github.io/kitchen-terraform/)\n - [InSpec](https://github.com/inspec/inspec-gcp)\n - [tftest](https://pypi.org/project/tftest/)\n- **End-to-end testing:** By extending the integration testing approach to an entire environment, you can confirm that multiple modules work together. In this approach, deploy all modules that make up the architecture in a fresh test environment. Ideally, the test environment is as similar as possible to your production environment. This is costly but provides the greatest confidence that changes don't break your production environment.\n\nStart small\n-----------\n\nMake sure that your tests iteratively build on each other. Consider running\nsmaller tests first and then working up to more complex tests, using a\n*fail fast* approach.\n\nRandomize project IDs and resource names\n----------------------------------------\n\nTo avoid naming conflicts, make sure that your configurations have a globally\nunique project ID and non-overlapping resource names within each project. To do\nthis, use namespaces for your resources. Terraform has a built-in\n[random provider](https://registry.terraform.io/providers/hashicorp/random/latest/docs)\nfor this.\n\nUse a separate environment for testing\n--------------------------------------\n\nDuring testing, many resources are created and deleted. Ensure that the\nenvironment is isolated from development or production projects to avoid\naccidental deletions during resource cleanup. The best approach is to have each\ntest create a fresh project or folder. To avoid misconfiguration, consider\ncreating service accounts specifically for each test execution.\n\nClean up all resources\n----------------------\n\nTesting infrastructure code means that you are deploying actual resources.\nTo avoid incurring charges, consider implementing a clean-up step.\n\nTo destroy all remote objects managed by a particular configuration, use the\n`terraform destroy` command. Some testing frameworks have a built-in cleanup\nstep for you. For example, if you are using Terratest, add\n`defer terraform.Destroy(t, terraformOptions)` to your test. If you're using\nKitchen-Terraform, delete your workspace using\n`terraform kitchen delete `\u003cvar translate=\"no\"\u003eWORKSPACE_NAME\u003c/var\u003e.\n\nAfter you run the `terraform destroy` command, also run additional clean-up\nprocedures to remove any resources that Terraform failed to destroy. Do this by\ndeleting any projects used for test execution or by using a tool like the\n[`project_cleanup`](https://github.com/terraform-google-modules/terraform-google-scheduled-function/tree/master/modules/project_cleanup) module.\n| **Warning:** Don't use such tools in a production environment.\n\nOptimize test runtime\n---------------------\n\nTo optimize your test execution time, use the following approaches:\n\n- **Run tests in parallel.** Some testing frameworks support running multiple Terraform tests simultaneously.\n - For example, with Terratest you can do this by adding `t.Parallel()` after the test function definition.\n- **Test in stages.** Separate your tests into independent configurations that can be tested separately. This approach removes the need to go through all stages when running a test, and accelerates the iterative development cycle.\n - For example, in Kitchen-Terraform, split tests into separate suites. When iterating, execute each suite independently.\n - Similarly, using Terratest, wrap each stage of your test with `stage(t, `\u003cvar translate=\"no\"\u003eSTAGE_NAME\u003c/var\u003e`, `\u003cvar translate=\"no\"\u003eCORRESPONDING_TEST\u003cem\u003eFUNCTION\u003c/em\u003e\u003c/var\u003e*)**.\n Set environment variables that indicate which tests to run. For example,\n `SKIP`* \u003cvar translate=\"no\"\u003eSTAGE_NAME\u003c/var\u003e`=\"true\"`.\n - The [blueprint testing framework](https://pkg.go.dev/github.com/GoogleCloudPlatform/cloud-foundation-toolkit/infra/blueprint-test) supports staged execution.\n\nWhat's next\n-----------\n\n- Learn about [general style and structure best practices for Terraform on Google Cloud](/docs/terraform/best-practices/general-style-structure).\n- Learn about [best practices when using Terraform root modules](/docs/terraform/best-practices/root-modules)."]]
