Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utiliser le framework AWS IoT Greengrass de test Greengrass Testing Framework (GTF) est un ensemble de composants qui soutiennent l' end-to-endautomatisation du point de vue du client. GTF utilise [Cucumber](https://cucumber.io) comme pilote de fonctionnalités. AWS IoT Greengrass utilise les mêmes éléments de base pour qualifier les modifications logicielles sur différents appareils. Pour plus d'informations, consultez [Greengrass Testing Framework sur](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1) Github. Le GTF est implémenté à l'aide de Cucumber, un outil utilisé pour exécuter des tests automatisés, afin d'encourager un développement des composants piloté par le comportement (BDD). Dans Cucumber, les fonctionnalités de ce système sont décrites dans un type de fichier spécial appelé`feature`. Chaque fonctionnalité est décrite dans un format lisible par l'homme appelé scénarios, qui sont des spécifications pouvant être converties en tests automatisés. Chaque scénario est décrit comme une série d'étapes qui définissent les interactions et les résultats de ce système testé à l'aide d'un langage spécifique au domaine appelé Gherkin. Une [étape Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) est liée au code de programmation à l'aide d'une méthode appelée définition d'étape qui relie la spécification au flux de test. Les définitions d'étapes dans GTF sont implémentées avec Java. **Topics** + [Comment ça marche](#gg-testing-framework-how-gtf-works) + [Journal des modifications](#gtf-changelog) + [Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md) + [Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass](run-e2e-tests-tutorial.md) + [Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance](confidence-tests-tutorial.md) ## Comment ça marche AWS IoT Greengrass distribue le GTF sous la forme d'un JAR autonome composé de plusieurs modules Java. Pour utiliser GTF pour end-to-end tester des composants, vous devez implémenter les tests dans un projet Java. L'ajout du JAR autonome de test en tant que dépendance dans votre projet Java vous permet d'utiliser les fonctionnalités existantes du GTF et de les étendre en écrivant vos propres cas de test personnalisés. Pour exécuter les scénarios de test personnalisés, vous pouvez créer votre projet Java et exécuter le fichier JAR cible avec les options de configuration décrites dans[Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md). ### JAR autonome GTF Greengrass utilise Cloudfront comme référentiel [Maven](https://maven.apache.org/) pour héberger différentes versions du JAR autonome GTF. Pour une liste complète des versions de GTF, voir les versions de [GTF.](https://github.com/aws-greengrass/aws-greengrass-testing/releases) Le JAR autonome GTF inclut les modules suivants. Il n'est pas limité à ces seuls modules. Vous pouvez sélectionner chacune de ces dépendances séparément dans votre projet ou les inclure toutes en même temps dans le [fichier JAR autonome de test](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone). + `aws-greengrass-testing-resources`: Ce module fournit une abstraction permettant de gérer le cycle de vie d'une AWS ressource au cours d'un test. Vous pouvez l'utiliser pour définir vos AWS ressources personnalisées à l'aide de l'`ResourceSpec`abstraction afin que GTF puisse s'occuper de la création et de la suppression de ces ressources pour vous. + `aws-greengrass-testing-platform`: Ce module fournit une abstraction au niveau de la plate-forme pour le périphérique testé pendant le cycle de vie du test. Il permet APIs d'interagir avec le système d'exploitation indépendamment de la plate-forme et peut être utilisé pour simuler les commandes exécutées dans le shell de l'appareil. + `aws-greengrass-testing-components`: Ce module comprend des exemples de composants utilisés pour tester les fonctionnalités principales de Greengrass, telles que les déploiements, l'IPC et d'autres fonctionnalités. + `aws-greengrass-testing-features`: Ce module comprend des étapes communes réutilisables et leurs définitions qui sont utilisées pour les tests dans l'environnement Greengrass. **Topics** + [Comment ça marche](#gg-testing-framework-how-gtf-works) + [Journal des modifications](#gtf-changelog) + [Options de configuration du Greengrass Testing Framework](configuration-options-gtf.md) + [Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass](run-e2e-tests-tutorial.md) + [Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance](confidence-tests-tutorial.md) ## Journal des modifications Le tableau suivant décrit les modifications apportées à chaque version du GTF. Pour plus d'informations, consultez la [page des versions du GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases) sur GitHub. | **Version** | **Modifications** | | --- | --- | | 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.0.0 | Première version. | # Options de configuration du Greengrass Testing Framework ## Options de configuration GTF Greengrass Testing Framework (GTF) vous permet de configurer certains paramètres lors du lancement du processus de end-to-end test afin d'orchestrer le flux de test. Vous pouvez spécifier ces options de configuration en tant qu'arguments CLI pour le JAR autonome GTF. Les versions 1.1.0 et ultérieures de GTF fournissent les options de configuration suivantes. + `additional-plugins`— (Facultatif) Plugins Cucumber supplémentaires + `aws-region`— Cible des points de terminaison régionaux spécifiques pour les AWS services. La valeur par défaut correspond à ce que le AWS SDK découvre. + `credentials-path`— Chemin d'accès facultatif aux informations d'identification du AWS profil. Par défaut, ce sont les informations d'identification découvertes sur l'environnement hôte. + `credentials-path-rotation`— Durée de rotation facultative pour les AWS informations d'identification. La valeur par défaut est 15 minutes ou`PT15M`. + `csr-path`— Le chemin du CSR à l'aide duquel le certificat de l'appareil sera généré. + `device-mode`— L'appareil cible testé. Par défaut, c'est le périphérique local. + `env-stage`— Cible l'environnement de déploiement de Greengrass. Par défaut, c'est la production. + `existing-device-cert-arn`— L'ARN d'un certificat existant que vous souhaitez utiliser comme certificat d'appareil pour Greengrass. + `feature-path`— Fichier ou répertoire contenant des fichiers de fonctionnalités supplémentaires. Par défaut, aucun fichier de fonctionnalités supplémentaire n'est utilisé. + `gg-cli-version`— Remplace la version de la CLI Greengrass. La valeur par défaut est celle trouvée dans. `ggc.version` + `gg-component-bucket`— Le nom d'un compartiment Amazon S3 existant qui héberge les composants Greengrass. + `gg-component-overrides`— Liste des remplacements de composants Greengrass. + `gg-persist`— Liste des éléments de test à conserver après un essai. Le comportement par défaut est de ne rien conserver. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`. + `gg-runtime`— Une liste de valeurs destinées à influencer la manière dont le test interagit avec les ressources de test. Ces valeurs remplacent le paramètre. `gg.persist` Si la valeur par défaut est vide, cela suppose que toutes les ressources de test sont gérées par scénario de test, y compris le moteur d'exécution Greengrass installé. Les valeurs acceptées sont : `aws.resources``installed.software`, et`generated.files`. + `ggc-archive`— Le chemin d'accès au composant du noyau Greengrass archivé. + `ggc-install-root`— Répertoire pour installer le composant Greengrass nucleus. La valeur par défaut est test.temp.path et le dossier test run. + `ggc-log-level`— Définissez le niveau logarithmique du noyau Greengrass pour le test. La valeur par défaut est « INFO ». + `ggc-tes-rolename`— Le rôle IAM que AWS IoT Greengrass Core assumera pour accéder aux AWS services. Si aucun rôle portant un nom donné n'existe, un rôle sera créé avec une politique d'accès par défaut. + `ggc-trusted-plugins`— La liste séparée par des virgules des chemins (sur l'hôte) des plugins fiables qui doivent être ajoutés à Greengrass. Pour fournir le chemin sur le DUT lui-même, préfixez-le par « dut : » + `ggc-user-name`— La valeur POSIXUser de user:group pour le noyau Greengrass. La valeur par défaut est le nom d'utilisateur actuel connecté. + `ggc-version`— Remplace la version du composant Greengrass nucleus en cours d'exécution. La valeur par défaut est celle trouvée dans ggc.archive. + `log-level`— Niveau de journalisation du test. La valeur par défaut est « INFO ». + `parallel-config`— Ensemble d'index de lots et de nombre de lots sous forme de chaîne JSON. La valeur par défaut de l'index des lots est 0 et le nombre de lots est 1. + `proxy-url`— Configurez tous les tests pour acheminer le trafic via cette URL. + `tags`— Exécutez uniquement des balises de fonctionnalité. Peut être intersecté avec « & » + `test-id-prefix`— Un préfixe commun appliqué à toutes les ressources spécifiques au test, y compris les noms de AWS ressources et les balises. Le préfixe par défaut est « gg ». + `test-log-path`— Répertoire qui contiendra les résultats de l'ensemble du test. La valeur par défaut est « TestResults ». + `test-results-json`— Indicateur permettant de déterminer si le rapport Cucumber JSON résultant est généré écrit sur le disque. La valeur par défaut est true (vrai). + `test-results-log`— Indicateur permettant de déterminer si la sortie de console est générée écrite sur le disque. La valeur par défaut est false. + `test-results-xml`— Indicateur permettant de déterminer si le rapport JUnit XML obtenu est généré et écrit sur le disque. La valeur par défaut est true (vrai). + `test-temp-path`— Répertoire pour générer des artefacts de test locaux. La valeur par défaut est un répertoire temporaire aléatoire préfixé par gg-testing. + `timeout-multiplier`— Multiplicateur fourni à tous les délais d'expiration des tests. La valeur par défaut est 1,0. # Tutoriel : Exécuter end-to-end des tests à l'aide du framework de test Greengrass et du kit de développement Greengrass AWS IoT Greengrass Le Testing Framework (GTF) et le Greengrass Development Kit (GDK) offrent aux développeurs des moyens d'exécuter des tests. end-to-end Vous pouvez suivre ce didacticiel pour initialiser un projet GDK avec un composant, initialiser un projet GDK avec un module de end-to-end test et créer un cas de test personnalisé. Après avoir créé votre scénario de test personnalisé, vous pouvez exécuter le test. Dans ce didacticiel, vous allez effectuer les opérations suivantes : 1. Initialisez un projet GDK avec un composant. 1. Initialisez un projet GDK avec un module de end-to-end test. 1. Créez un cas de test personnalisé. 1. Ajoutez une étiquette au nouveau scénario de test. 1. Créez le fichier JAR de test. 1. Exécutez le test . **Topics** + [Conditions préalables](#run-e2e-tests-tutorial-prerequisites) + [Étape 1 : Initialisation d'un projet GDK avec un composant](#init-gdk-with-component) + [Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end](#init-gdk-with-e2e-test) + [Étape 3 : créer un cas de test personnalisé](#run-e2e-tests-tutorial-instructions) + [Étape 4 : ajouter un tag au nouveau scénario de test](#add-tag-to-test-case) + [Étape 5 : créer le fichier JAR de test](#build-test-jar) + [Étape 6 : Exécuter le test](#run-test-gtf) + [Exemple : création d'un scénario de test personnalisé](#build-test-case-example) ## Conditions préalables Pour suivre ce didacticiel, vous aurez besoin des éléments suivants : + GDK version 1.3.0 ou ultérieure + Java + Maven + Git ## Étape 1 : Initialisation d'un projet GDK avec un composant + Initialisez un dossier vide avec un projet GDK. Téléchargez le `HelloWorld` composant implémenté en Python en exécutant la commande suivante. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Cette commande crée un nouveau répertoire nommé `HelloWorld` dans le répertoire en cours. ## Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end + GDK vous permet de télécharger le modèle du module de test composé d'une fonctionnalité et d'une implémentation par étapes. Exécutez la commande suivante pour ouvrir le `HelloWorld` répertoire et initialiser le projet GDK existant à l'aide d'un module de test. ``` cd HelloWorld gdk test-e2e init ``` Cette commande crée un nouveau répertoire nommé `gg-e2e-tests` dans le `HelloWorld` répertoire. Ce répertoire de test est un projet [Maven](https://maven.apache.org/) qui dépend du JAR autonome de test Greengrass. ## Étape 3 : créer un cas de test personnalisé La rédaction d'un scénario de test personnalisé comprend généralement deux étapes : créer un fichier de fonctionnalités avec un scénario de test et implémenter les définitions d'étapes. Pour un exemple de création d'un scénario de test personnalisé, voir[Exemple : création d'un scénario de test personnalisé](#build-test-case-example). Suivez les étapes suivantes pour créer votre scénario de test personnalisé : 1. Création d'un fichier de fonctionnalités avec un scénario de test Une fonctionnalité décrit généralement une fonctionnalité spécifique du logiciel testé. Dans Cucumber, chaque fonctionnalité est spécifiée sous la forme d'un fichier de fonctionnalités individuel avec un titre, une description détaillée et un ou plusieurs exemples de cas spécifiques appelés scénarios. Chaque scénario comprend un titre, une description détaillée et une série d'étapes qui définissent les interactions et les résultats attendus. Les scénarios sont rédigés dans un format structuré à l'aide des mots clés « donné », « quand » et « alors ». 1. Mettre en œuvre les définitions des étapes Une définition d'étape lie l'[étape Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) en langage clair au code programmatique. Lorsque Cucumber identifie une étape Gherkin dans un scénario, il recherche une définition d'étape correspondante à exécuter. ## Étape 4 : ajouter un tag au nouveau scénario de test + Vous pouvez attribuer des balises aux fonctionnalités et aux scénarios afin d'organiser le processus de test. Vous pouvez utiliser des balises pour classer les sous-ensembles de scénarios et également sélectionner les hooks à exécuter de manière conditionnelle. Les fonctionnalités et les scénarios peuvent comporter plusieurs balises séparées par un espace. Dans cet exemple, nous utilisons le `HelloWorld` composant. Dans le fichier de fonctionnalités, ajoutez une nouvelle balise nommée `@HelloWorld` à côté de la `@Sample` balise. ``` @Sample @HelloWorld Scenario: As a developer, I can create a component and deploy it on my device .... ``` ## Étape 5 : créer le fichier JAR de test 1. Construisez le composant. Vous devez créer le composant avant de créer le module de test. ``` gdk component build ``` 1. Créez le module de test à l'aide de la commande suivante. Cette commande créera le fichier JAR de test dans le `greengrass-build` dossier. ``` gdk test-e2e build ``` ## Étape 6 : Exécuter le test Lorsque vous exécutez un scénario de test personnalisé, le GTF automatise le cycle de vie du test ainsi que la gestion des ressources créées pendant le test. Il approvisionne d'abord un appareil en cours de test (DUT) en tant qu' AWS IoT objet et y installe le logiciel de base Greengrass. Il créera ensuite un nouveau composant nommé `HelloWorld` en utilisant la recette spécifiée dans ce chemin. Le `HelloWorld` composant est ensuite déployé sur le périphérique principal par le biais d'un déploiement d'objets Greengrass. Il sera ensuite vérifié si le déploiement est réussi. L'état du déploiement passera à 3 `COMPLETED` minutes si le déploiement est réussi. 1. Accédez au `gdk-config.json` fichier dans le répertoire du projet pour cibler les tests avec la `HelloWorld` balise. Mettez à jour la `test-e2e` clé à l'aide de la commande suivante. ``` "test-e2e":{ "gtf_options" : { "tags":"HelloWorld" } } ``` 1. Avant d'exécuter les tests, vous devez fournir des AWS informations d'identification au périphérique hôte. GTF utilise ces informations d'identification pour gérer les AWS ressources pendant le processus de test. Assurez-vous que le rôle que vous fournissez dispose des autorisations nécessaires pour automatiser les opérations nécessaires incluses dans le test. Exécutez les commandes suivantes pour fournir les AWS informations d'identification. 1. ------ #### [ Linux or Unix ] ``` export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ Windows Command Prompt (CMD) ] ``` set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ PowerShell ] ``` $env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" $env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" ``` ------ 1. Exécutez le test à l'aide de la commande suivante. ``` gdk test-e2e run ``` Cette commande télécharge la dernière version du noyau Greengrass dans le `greengrass-build` dossier et exécute des tests en l'utilisant. Cette commande cible également uniquement les scénarios dotés de la `HelloWorld` balise et génère un rapport pour ces scénarios. Vous verrez que les AWS ressources créées lors de ce test sont supprimées à la fin du test. ## Exemple : création d'un scénario de test personnalisé **Example** Le module de test téléchargé dans le projet GDK se compose d'un exemple de fonctionnalité et d'un fichier d'implémentation des étapes. Dans l'exemple suivant, nous créons un fichier de fonctionnalités pour tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Nous testons partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via Greengrass AWS Cloud. Il s'agit d'une série d'étapes qui nous aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation. 1. **Création d'un fichier de fonctionnalités** Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Vous pouvez trouver l'exemple `component.feature` qui ressemble à l'exemple suivant. Dans ce fichier de fonctionnalités, vous pouvez tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Vous pouvez tester partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via le cloud Greengrass. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation. ``` Feature: Testing features of Greengrassv2 component Background: Given my device is registered as a Thing And my device is running Greengrass @Sample Scenario: As a developer, I can create a component and deploy it on my device When I create a Greengrass deployment with components HelloWorld | /path/to/recipe/file And I deploy the Greengrass deployment configuration Then the Greengrass deployment is COMPLETED on the device after 180 seconds And I call my custom step ``` GTF contient les définitions des étapes de toutes les étapes suivantes, à l'exception de l'étape nommée :`And I call my custom step`. 1. **Mettre en œuvre les définitions des étapes** Le fichier JAR autonome GTF contient les définitions d'étapes de toutes les étapes à l'exception d'une étape :. `And I call my custom step` Vous pouvez implémenter cette étape dans le module de test. Accédez au code source du fichier de test. Vous pouvez lier votre étape personnalisée à l'aide d'une définition d'étape à l'aide de la commande suivante. ``` @And("I call my custom step") public void customStep() { System.out.println("My custom step was called "); } ``` # Tutoriel : Utiliser un test de confiance issu de la suite de tests de confiance AWS IoT Greengrass Le Testing Framework (GTF) et le Greengrass Development Kit (GDK) offrent aux développeurs des moyens d'exécuter des tests. end-to-end Vous pouvez suivre ce didacticiel pour initialiser un projet GDK avec un composant, initialiser un projet GDK avec un module de test et utiliser un end-to-end test de confiance issu de la suite de tests de confiance. Après avoir créé votre scénario de test personnalisé, vous pouvez exécuter le test. Un test de confiance est un test générique fourni par Greengrass qui valide les comportements fondamentaux des composants. Ces tests peuvent être modifiés ou étendus pour répondre à des besoins de composants plus spécifiques. Pour ce didacticiel, nous utiliserons un HelloWorld composant. Si vous utilisez un autre composant, remplacez-le par le HelloWorld vôtre. Dans ce didacticiel, vous allez effectuer les opérations suivantes : 1. Initialisez un projet GDK avec un composant. 1. Initialisez un projet GDK avec un module de end-to-end test. 1. Utilisez un test issu de la suite de tests de confiance. 1. Ajoutez une étiquette au nouveau scénario de test. 1. Créez le fichier JAR de test. 1. Exécutez le test . **Topics** + [Conditions préalables](#confidence-tests-tutorial-prerequisites) + [Étape 1 : Initialisation d'un projet GDK avec un composant](#init-gdk-with-component) + [Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end](#init-gdk-with-e2e-test) + [Étape 3 : Utiliser un test issu de la suite de tests de confiance](#confidence-tests-tutorial-instructions) + [Étape 4 : ajouter un tag au nouveau scénario de test](#add-tag-to-test-case) + [Étape 5 : créer le fichier JAR de test](#build-test-jar) + [Étape 6 : Exécuter le test](#run-test-gtf) + [Exemple : utiliser un test de confiance](#build-confidence-test-case-example) ## Conditions préalables Pour suivre ce didacticiel, vous aurez besoin des éléments suivants : + GDK version 1.6.0 ou ultérieure + Java + Maven + Git ## Étape 1 : Initialisation d'un projet GDK avec un composant + Initialisez un dossier vide avec un projet GDK. Téléchargez le `HelloWorld` composant implémenté en Python en exécutant la commande suivante. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Cette commande crée un nouveau répertoire nommé `HelloWorld` dans le répertoire en cours. ## Étape 2 : Initialisation d'un projet GDK avec un module de test end-to-end + GDK vous permet de télécharger le modèle du module de test composé d'une fonctionnalité et d'une implémentation par étapes. Exécutez la commande suivante pour ouvrir le `HelloWorld` répertoire et initialiser le projet GDK existant à l'aide d'un module de test. ``` cd HelloWorld gdk test-e2e init ``` Cette commande crée un nouveau répertoire nommé `gg-e2e-tests` dans le `HelloWorld` répertoire. Ce répertoire de test est un projet [Maven](https://maven.apache.org/) qui dépend du JAR autonome de test Greengrass. ## Étape 3 : Utiliser un test issu de la suite de tests de confiance La rédaction d'un scénario de test de confiance consiste à utiliser le fichier de fonctionnalités fourni et, si nécessaire, à modifier les scénarios. Pour un exemple d'utilisation d'un test de confiance, voir[Exemple : création d'un scénario de test personnalisé](run-e2e-tests-tutorial.md#build-test-case-example). Pour utiliser un test de confiance, procédez comme suit : + Utilisez le fichier de fonctionnalités fourni. Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Ouvrez le `confidenceTest.feature` fichier d'exemple pour utiliser le test de confiance. ## Étape 4 : ajouter un tag au nouveau scénario de test + Vous pouvez attribuer des balises aux fonctionnalités et aux scénarios afin d'organiser le processus de test. Vous pouvez utiliser des balises pour classer les sous-ensembles de scénarios et également sélectionner les hooks à exécuter de manière conditionnelle. Les fonctionnalités et les scénarios peuvent comporter plusieurs balises séparées par un espace. Dans cet exemple, nous utilisons le `HelloWorld` composant. Chaque scénario est étiqueté avec`@ConfidenceTest`. Modifiez ou ajoutez des balises si vous souhaitez exécuter uniquement un sous-ensemble de la suite de tests. Chaque scénario de test est décrit en haut de chaque test de confiance. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de chaque cas de test. Vous pouvez étendre ces tests en ajoutant vos propres étapes ou en modifiant les étapes existantes. ``` @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected .... ``` ## Étape 5 : créer le fichier JAR de test 1. Construisez le composant. Vous devez créer le composant avant de créer le module de test. ``` gdk component build ``` 1. Créez le module de test à l'aide de la commande suivante. Cette commande créera le fichier JAR de test dans le `greengrass-build` dossier. ``` gdk test-e2e build ``` ## Étape 6 : Exécuter le test Lorsque vous exécutez un test de confiance, le GTF automatise le cycle de vie du test ainsi que la gestion des ressources créées pendant le test. Il approvisionne d'abord un appareil en cours de test (DUT) en tant qu' AWS IoT objet et y installe le logiciel de base Greengrass. Il créera ensuite un nouveau composant nommé `HelloWorld` en utilisant la recette spécifiée dans ce chemin. Le `HelloWorld` composant est ensuite déployé sur le périphérique principal par le biais d'un déploiement d'objets Greengrass. Il sera ensuite vérifié si le déploiement est réussi. L'état du déploiement passera à 3 `COMPLETED` minutes si le déploiement est réussi. 1. Accédez au `gdk-config.json` fichier dans le répertoire du projet pour cibler les tests avec le `ConfidenceTest` tag ou le tag yo8u spécifié à l'étape 4. Mettez à jour la `test-e2e` clé à l'aide de la commande suivante. ``` "test-e2e":{ "gtf_options" : { "tags":"ConfidenceTest" } } ``` 1. Avant d'exécuter les tests, vous devez fournir des AWS informations d'identification au périphérique hôte. GTF utilise ces informations d'identification pour gérer les AWS ressources pendant le processus de test. Assurez-vous que le rôle que vous fournissez dispose des autorisations nécessaires pour automatiser les opérations nécessaires incluses dans le test. Exécutez les commandes suivantes pour fournir les AWS informations d'identification. 1. ------ #### [ Linux or Unix ] ``` export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ Windows Command Prompt (CMD) ] ``` set AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE set AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY ``` ------ #### [ PowerShell ] ``` $env:AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE" $env:AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" ``` ------ 1. Exécutez le test à l'aide de la commande suivante. ``` gdk test-e2e run ``` Cette commande télécharge la dernière version du noyau Greengrass dans le `greengrass-build` dossier et exécute des tests en l'utilisant. Cette commande cible également uniquement les scénarios dotés de la `ConfidenceTest` balise et génère un rapport pour ces scénarios. Vous verrez que les AWS ressources créées lors de ce test sont supprimées à la fin du test. ## Exemple : utiliser un test de confiance **Example** Le module de test téléchargé dans le projet GDK consiste en un fichier de fonctionnalités fourni. Dans l'exemple suivant, nous utilisons un fichier de fonctionnalités pour tester la fonctionnalité de déploiement d'objets du logiciel Greengrass. Nous testons partiellement la fonctionnalité de cette fonctionnalité avec un scénario qui effectue le déploiement d'un composant via Greengrass AWS Cloud. Il s'agit d'une série d'étapes qui nous aident à comprendre les interactions et les résultats attendus de ce cas d'utilisation. + **Utilisez le fichier de fonctionnalités fourni.** Accédez au `gg-e2e-tests/src/main/resources/greengrass/features` dossier dans le répertoire actuel. Vous pouvez trouver l'exemple `confidenceTest.feature` qui ressemble à l'exemple suivant. ``` Feature: Confidence Test Suite Background: Given my device is registered as a Thing And my device is running Greengrass @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected When I create a Greengrass deployment with components | GDK_COMPONENT_NAME | GDK_COMPONENT_RECIPE_FILE | | aws.greengrass.Cli | LATEST | And I deploy the Greengrass deployment configuration Then the Greengrass deployment is COMPLETED on the device after 180 seconds # Update component state accordingly. Possible states: {RUNNING, FINISHED, BROKEN, STOPPING} And I verify the GDK_COMPONENT_NAME component is RUNNING using the greengrass-cli ``` Chaque scénario de test est décrit en haut de chaque test de confiance. Le scénario est une série d'étapes qui aident à comprendre les interactions et les résultats attendus de chaque cas de test. Vous pouvez étendre ces tests en ajoutant vos propres étapes ou en modifiant les étapes existantes. Chacun des scénarios inclut des commentaires qui vous aideront à effectuer ces ajustements.