Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document fournit des consignes et des recommandations pour tester les modules et les configurations Terraform pour Google Cloud.
Le test des modules et des configurations Terraform suit parfois des modèles et des conventions différents de ceux des tests utilisés pour du code d'application. Bien que les tests de code d'application impliquent principalement de tester la logique métier des applications elles-mêmes, le test complet du code d'infrastructure nécessite le déploiement de ressources cloud réelles pour minimiser le risque de défaillances de production. Vous devez prendre en compte quelques éléments lors de l'exécution de tests Terraform :
L'exécution d'un test Terraform crée, modifie et supprime une infrastructure réelle. Vos tests peuvent donc prendre beaucoup de temps et être coûteux.
Vous ne pouvez pas effectuer de tests unitaires pour une architecture de bout en bout. La meilleure approche consiste à diviser votre architecture en modules et à les tester individuellement. Les avantages de cette approche sont les suivants : le développement itératif est plus rapide, car l'environnement d'exécution des tests est plus rapide, les coûts pour chaque test sont réduits et le risque d'échecs liés aux facteurs échappant à votre contrôle est également réduit.
Évitez de réutiliser l'état si possible. Il peut arriver d'avoir à effectuer des tests avec des configurations partageant des données avec d'autres configurations. Idéalement, chaque test doit être indépendant et ne pas réutiliser l'état entre différents tests.
Utiliser d'abord des méthodes de test moins coûteuses
Vous disposez de plusieurs méthodes pour tester Terraform. Par ordre croissant de coût, de temps d'exécution et de profondeur, ces méthodes incluent les suivantes :
Analyse statique : test de la syntaxe et de la structure de votre configuration sans déployer de ressources, à l'aide d'outils tels que les compilateurs, les fonctions linters et les simulations. Pour ce faire, utilisez
terraform validate.
Tests d'intégration des modules : pour vous assurer que les modules fonctionnent correctement, testez-les individuellement. Les tests d'intégration des modules impliquent le déploiement du module dans un environnement de test et la vérification de la création des ressources attendues. Plusieurs frameworks de test facilitent l'écriture de tests, comme suit :
Tests de bout en bout : en étendant l'approche des tests d'intégration à un environnement complet, vous pouvez vérifier que plusieurs modules fonctionnent correctement ensemble.
Dans cette approche, déployez tous les modules qui composent l'architecture dans un environnement de test récent. Idéalement, l'environnement de test est aussi semblable que possible à votre environnement de production. Bien que plus coûteuse, cette méthode offre le plus haut niveau de confiance pour garantir que les modifications ne nuisent pas à votre environnement de production.
Procéder par étapes
Assurez-vous que vos tests se compilent les uns les autres de manière itérative. Envisagez d'abord d'exécuter des tests plus petits pour avancer progressivement vers des tests plus complexes, en adoptant une approche basée sur les échecs rapides.
Randomiser les ID de projet et les noms de ressources
Pour éviter les conflits de noms, assurez-vous que vos configurations ont un ID de projet global unique et des noms de ressources qui ne se chevauchent pas au sein de chaque projet. Pour ce faire, utilisez des espaces de noms pour vos ressources. Terraform dispose d'un fournisseur aléatoire intégré.
Utiliser un environnement distinct pour les tests
Pendant les tests, de nombreuses ressources sont créées et supprimées. Assurez-vous que l'environnement est isolé des projets de développement ou de production afin d'éviter toute suppression accidentelle lors du nettoyage des ressources. La meilleure approche consiste à demander à chaque test de créer un nouveau projet ou un nouveau dossier. Pour éviter toute erreur de configuration, envisagez de créer des comptes de service spécifiques pour chaque exécution de test.
Nettoyer toutes les ressources
Tester le code d'infrastructure signifie que vous déployez des ressources réelles.
Pour éviter des frais, envisagez de mettre en œuvre une étape de nettoyage.
Pour détruire tous les objets distants gérés par une configuration spécifique, utilisez la commande terraform destroy. Certains frameworks de test disposent d'une étape de nettoyage intégrée. Par exemple, si vous utilisez Terratest, ajoutez defer terraform.Destroy(t, terraformOptions) à votre test. Si vous utilisez Kitchen-Terraform, supprimez votre espace de travail en utilisant terraform kitchen delete WORKSPACE_NAME.
Après avoir exécuté la commande terraform destroy, exécutez également des procédures de nettoyage supplémentaires pour supprimer toutes les ressources que Terraform n'a pas pu détruire. Pour ce faire, supprimez tous les projets utilisés pour exécuter le test ou utilisez un outil tel que le module project_cleanup.
Optimiser le temps d'exécution des tests
Pour optimiser le temps d'exécution des tests, utilisez les approches suivantes :
Exécuter des tests en parallèle. Certains frameworks de tests permettent d'exécuter simultanément plusieurs tests Terraform.
Par exemple, avec Terratest, vous pouvez pour cela ajouter t.Parallel() après la définition de la fonction de test.
Tester par étapes. Séparez vos tests en configurations indépendantes pouvant être testées séparément. Cette approche vous évite d'avoir à passer toutes les étapes lors de test et accélère le cycle de développement itératif.
Par exemple, dans la Kitchen-Terraform, divisez les tests en suites distinctes. Pendant l'itération, exécutez chaque suite indépendamment.
De même, avec Terratest, encapsulez chaque étape de votre test avec stage(t, STAGE_NAME, CORRESPONDING_TESTFUNCTION).
Définissez des variables d'environnement indiquant les tests à exécuter. Par exemple,
SKIPSTAGE_NAME="true"
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/12/22 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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)."]]
