As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Use a estrutura AWS IoT Greengrass de teste O Greengrass Testing Framework (GTF) é uma coleção de componentes básicos que oferece suporte à end-to-end automação do ponto de vista do cliente. O GTF usa [Cucumber](https://cucumber.io) como driver de recursos. AWS IoT Greengrass usa os mesmos componentes básicos para qualificar as alterações de software em vários dispositivos. Para mais informações, consulte [Estrutura de testes do Greengrass no Github](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1). O GTF é implementado usando o Cucumber, uma ferramenta usada para executar testes automatizados, para incentivar o desenvolvimento orientado pelo comportamento (BDD) dos componentes. No Cucumber, os atributos desse sistema são descritos em um tipo especial de arquivo chamado `feature`. Cada atributo é descrito em um formato legível por humanos chamado cenários, que são especificações que podem ser convertidas em testes automatizados. Cada cenário é descrito como uma série de etapas que definem as interações e os resultados desse sistema em teste usando uma linguagem específica de domínio chamada Gherkin. Uma [etapa Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) é vinculada ao código de programação usando um método chamado definição de etapa, que conecta a especificação ao fluxo de teste. As definições de etapas no GTF são implementadas com Java. **Topics** + [Como funciona](#gg-testing-framework-how-gtf-works) + [Changelog](#gtf-changelog) + [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md) + [Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit](run-e2e-tests-tutorial.md) + [Tutorial: usar um teste de confiança do conjunto de testes de confiança](confidence-tests-tutorial.md) ## Como funciona AWS IoT Greengrass distribui o GTF como um JAR autônomo que consiste em vários módulos Java. Para usar o GTF para end-to-end testar componentes, você deve implementar os testes em um projeto Java. Adicionar o JAR padrão de teste como uma dependência em seu projeto Java permite que você use a funcionalidade existente do GTF e a estenda escrevendo seus próprios casos de teste personalizados. Para executar os casos de teste personalizados, você pode criar seu projeto Java e executar o JAR de destino com as opções de configuração descritas em [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md). ### JAR autônomo do GTF O Greengrass usa o Cloudfront como um repositório [Maven](https://maven.apache.org/) para hospedar diferentes versões do JAR autônomo do GTF. Para uma lista completa das versões do GTF, consulte os [lançamentos do GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases). O JAR autônomo do GTF inclui os seguintes módulos. Não se limita apenas a esses módulos. Você pode escolher cada uma dessas dependências separadamente em seu projeto ou incluí-las todas de uma vez com o [arquivo JAR autônomo de teste](https://github.com/aws-greengrass/aws-greengrass-testing/tree/dev_v1/aws-greengrass-testing-standalone). + `aws-greengrass-testing-resources`: este módulo fornece abstração para gerenciar o ciclo de vida de um AWS recurso durante o curso de um teste. Você pode usar isso para definir seus AWS recursos personalizados usando `ResourceSpec` abstração para que o GTF possa cuidar da criação e remoção desses recursos para você. + `aws-greengrass-testing-platform`: este módulo fornece abstração em nível de plataforma para o dispositivo em teste durante o ciclo de vida do teste. Ele é APIs usado para interagir com o sistema operacional independente da plataforma e pode ser usado para simular os comandos em execução no shell do dispositivo. + `aws-greengrass-testing-components`: este módulo consiste em amostras de componentes que são usados para testar os atributos de núcleo do Greengrass, como implantações, IPC e outros. + `aws-greengrass-testing-features`: este módulo consiste em etapas comuns reutilizáveis e as definições delas, que são usadas para testes no ambiente Greengrass. **Topics** + [Como funciona](#gg-testing-framework-how-gtf-works) + [Changelog](#gtf-changelog) + [Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework)](configuration-options-gtf.md) + [Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit](run-e2e-tests-tutorial.md) + [Tutorial: usar um teste de confiança do conjunto de testes de confiança](confidence-tests-tutorial.md) ## Changelog A tabela a seguir descreve as alterações em cada versão do GTF. Para obter mais informações, consulte a [página de lançamentos do GTF](https://github.com/aws-greengrass/aws-greengrass-testing/releases) em. GitHub | **Versão** | **Alterações** | | --- | --- | | 1.2.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.1.0 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/greengrass/v2/developerguide/gg-testing-framework.html) | | 1.0.0 | Versão inicial. | # Opções de configuração da estrutura de testes do Greengrass (Greengrass Testing Framework) ## Opções de configuração do GTF O GTF permite que você configure determinados parâmetros durante o lançamento do processo de teste de ponta a ponta para orquestrar o fluxo de teste. É possível especificar essas opções de configuração como argumentos de CLI para o JAR autônomo do GTF. A versão 1.1.0 e posteriores do GTF oferecem as seguintes opções de configuração. + `additional-plugins`: (opcional) plug-ins adicionais do Cucumber + `aws-region`: tem como alvo endpoints regionais específicos para serviços da AWS. O padrão é o que o SDK da AWS descobre. + `credentials-path`: caminho opcional de credenciais do perfil da AWS. O padrão é credenciais descobertas no ambiente do host. + `credentials-path-rotation`: duração de rotação opcional para credenciais da AWS. O valor padrão é 15 minutos ou `PT15M`. + `csr-path`: o caminho para o CSR usando qual certificado do dispositivo será gerado. + `device-mode`: o dispositivo alvo em teste. O padrão é o dispositivo local. + `env-stage`: tem como alvo o ambiente de implantação do Greengrass. O padrão é produção. + `existing-device-cert-arn`: o arn de um certificado existente que você deseja usar como certificado de dispositivo para o Greengrass. + `feature-path`: arquivo ou diretório contendo arquivos de atributos adicionais. O padrão é não usar nenhum arquivo de atributo adicional. + `gg-cli-version`: substitui a versão da CLI do Greengrass. O padrão é o valor encontrado em `ggc.version`. + `gg-component-bucket`: o nome de um bucket existente do Amazon S3 que abriga os componentes do Greengrass. + `gg-component-overrides`: uma lista de substituições de componentes do Greengrass. + `gg-persist`: uma lista de elementos de teste a serem persistidos após a execução do teste. O comportamento padrão é não persistir em nada. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`. + `gg-runtime`: uma lista de valores para influenciar a forma como o teste interage com os recursos do teste. Esses valores substituem o parâmetro `gg.persist`. Se o padrão for vazio, ele presume que todos os recursos de teste são gerenciados pelo caso de teste, incluindo o runtime do Greengrass instalado. Os valores aceitos são `aws.resources`, `installed.software` e `generated.files`. + `ggc-archive`: o caminho para o componente do núcleo arquivado do Greengrass. + `ggc-install-root`: diretório para instalar o componente do núcleo do Greengrass. O padrão é test.temp.path e pasta de execução de teste. + `ggc-log-level`: defina o nível de log do núcleo do Greengrass para a execução do teste. O padrão é "INFO". + `ggc-tes-rolename`: o perfil do IAM que o AWS IoT Greengrass Core assumirá para acessar os serviços da AWS. Se um perfil com o nome fornecido não existir, será criada uma política de acesso padrão. + `ggc-trusted-plugins`: a lista separada por vírgula dos caminhos (no host) dos plug-ins confiáveis que precisam ser adicionados ao Greengrass. Para fornecer o caminho no próprio DUT, adicione o prefixo o caminho com 'dut': + `ggc-user-name`: o valor de user:group PosixUser para o núcleo do Greengrass. O padrão é o nome de usuário atual que está conectado. + `ggc-version`: substitui a versão do componente do núcleo do Greengrass em execução. O padrão é o valor encontrado em ggc.archive. + `log-level`: nível de log da execução do teste. O padrão é "INFO". + `parallel-config`: conjunto de índice de lote e número de lotes como uma string JSON. O valor padrão do índice do lote é 0 e o número de lotes é 1. + `proxy-url`: configure todos os testes para rotear o tráfego por meio desse URL. + `tags`: executa apenas tags de recursos. Pode ser cruzado com '&' + `test-id-prefix`: um prefixo comum aplicado a todos os recursos específicos do teste, incluindo nomes e tags de recursos da AWS. O padrão é um prefixo "gg". + `test-log-path`: diretório que conterá os resultados de toda a execução do teste. O padrão é "testResults". + `test-results-json`: sinalize para determinar se um relatório JSON do Cucumber resultante foi gerado e gravado no disco. O valor padrão é verdadeiro. + `test-results-log`: sinalize para determinar se a saída do console foi gerada e gravada no disco. O padrão é falso. + `test-results-xml`: sinalize para determinar se um relatório XML JUnit resultante é gerado e gravado em disco. O valor padrão é verdadeiro. + `test-temp-path`: diretório para gerar artefatos de teste locais. O padrão é um diretório temporário aleatório prefixado com gg-testing. + `timeout-multiplier`: multiplicador fornecido para todos os tempos limite de teste. O padrão é 1.0. # Tutorial: Execute end-to-end testes usando o Greengrass Testing Framework e o Greengrass Development Kit AWS IoT Greengrass O Testing Framework (GTF) e o Greengrass Development Kit (GDK) oferecem aos desenvolvedores maneiras de executar testes. end-to-end Você pode concluir este tutorial para inicializar um projeto do GDK com um componente, inicializar um projeto do GDK com um módulo de end-to-end teste e criar um caso de teste personalizado. Depois de criar seu caso de teste personalizado, você poderá executar o teste. Neste tutorial, você faz o seguinte: 1. Inicialize um projeto do GDK com um componente. 1. Inicialize um projeto GDK com um módulo de end-to-end teste. 1. Crie um caso de teste personalizado. 1. Adicione uma tag ao novo caso de teste. 1. Crie o JAR de teste. 1. Execute o teste do . **Topics** + [Pré-requisitos](#run-e2e-tests-tutorial-prerequisites) + [Etapa 1: inicializar um projeto do GDK com um componente](#init-gdk-with-component) + [Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste](#init-gdk-with-e2e-test) + [Etapa 3: definir um caso de teste personalizado](#run-e2e-tests-tutorial-instructions) + [Etapa 4: Adicionar uma tag ao novo caso de teste](#add-tag-to-test-case) + [Etapa 5: compilar o JAR de teste](#build-test-jar) + [Etapa 6: executar o teste](#run-test-gtf) + [Exemplo: criar um caso de teste personalizado](#build-test-case-example) ## Pré-requisitos Para concluir este tutorial, você precisará do seguinte: + GDK versão 1.3.0 ou posterior + Java + Maven + Git ## Etapa 1: inicializar um projeto do GDK com um componente + Inicialize uma pasta vazia com um projeto do GDK. Faça download do componente `HelloWorld` implementado em Python executando o comando a seguir. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Esse comando cria um diretório chamado `HelloWorld` no diretório atual. ## Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste + O GDK permite que você baixe o modelo do módulo de teste que consiste em uma implementação de atributos e etapas. Execute o comando a seguir para abrir o diretório `HelloWorld` e inicializar o projeto GDK existente usando um módulo de teste. ``` cd HelloWorld gdk test-e2e init ``` Esse comando cria um diretório chamado `gg-e2e-tests` no diretório `HelloWorld`. Esse diretório de teste é um projeto [Maven](https://maven.apache.org/) que depende do JAR independente de testes do Greengrass. ## Etapa 3: definir um caso de teste personalizado Escrever um caso de teste personalizado consiste basicamente em duas etapas: criar um arquivo de recurso com um cenário de teste e implementar as definições das etapas. Para ver um exemplo de criação de um caso de teste personalizado, consulte [Exemplo: criar um caso de teste personalizado](#build-test-case-example). Use as etapas a seguir para criar seu caso de teste personalizado: 1. Criar um arquivo de recurso com um cenário de teste Um recurso geralmente descreve uma funcionalidade específica do software que está sendo testado. No Cucumber, cada recurso é especificado como um arquivo de recurso individual com um título, uma descrição detalhada e um ou mais exemplos de casos específicos chamados cenários. Cada cenário consiste em um título, uma descrição detalhada e uma série de etapas que definem as interações e os resultados esperados. Os cenários são escritos em um formato estruturado usando as palavras-chave “determinado”, “quando” e “então”. 1. Implementar definições de etapas Uma definição de etapa vincula a [etapa Gherkin](https://cucumber.io/docs/gherkin/reference/#steps) em linguagem simples ao código programático. Quando o Cucumber identifica uma etapa do Gherkin em um cenário, ele procura uma definição de etapa correspondente para ser executada. ## Etapa 4: Adicionar uma tag ao novo caso de teste + Você pode atribuir tags aos atributos e cenários para organizar o processo de teste. Você pode usar tags para categorizar os subconjuntos de cenários e também selecionar hooks condicionalmente para execução. Os atributos e os cenários podem ter várias tags separadas por um espaço. Neste exemplo, usamos o componente `HelloWorld`. No arquivo de recurso, adicione uma nova tag chamada `@HelloWorld` ao lado da tag `@Sample`. ``` @Sample @HelloWorld Scenario: As a developer, I can create a component and deploy it on my device .... ``` ## Etapa 5: compilar o JAR de teste 1. Crie o componente. Você deve criar o componente antes de criar o módulo de teste. ``` gdk component build ``` 1. Crie o módulo de teste usando o comando a seguir. Esse comando criará o JAR de teste na pasta `greengrass-build`. ``` gdk test-e2e build ``` ## Etapa 6: executar o teste Quando você executa um caso de teste personalizado, o GTF automatiza o ciclo de vida do teste junto com o gerenciamento de recursos que foram criados durante o teste. Primeiro, ele provisiona um dispositivo em teste (DUT) como uma AWS IoT coisa e instala o software principal do Greengrass nele. Em seguida, ele criará um novo componente chamado `HelloWorld` usando a fórmula especificada nesse caminho. O componente do `HelloWorld` é então implantado no dispositivo principal por meio de uma implantação da coisa do Greengrass. Em seguida, é verificado se a implantação foi bem-sucedida. O status da implantação será alterado para `COMPLETED` dentro de 3 minutos se a implantação for bem-sucedida. 1. Vá para o arquivo `gdk-config.json` no diretório do projeto para direcionar os testes com a tag `HelloWorld`. Atualize a chave `test-e2e` usando o comando a seguir. ``` "test-e2e":{ "gtf_options" : { "tags":"HelloWorld" } } ``` 1. Antes de executar os testes, você deve fornecer AWS credenciais para o dispositivo host. O GTF usa essas credenciais para gerenciar os AWS recursos durante o processo de teste. Certifique-se de que o perfil fornecido tenha permissões para automatizar as operações necessárias incluídas no teste. Execute os comandos a seguir para fornecer as AWS credenciais. 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. Execute o teste usando o seguinte comando. ``` gdk test-e2e run ``` Esse comando baixa a versão mais recente do núcleo do Greengrass na pasta `greengrass-build` e executa testes usando-a. Esse comando também visa somente os cenários com a tag `HelloWorld` e gera um relatório para eles. Você verá que os AWS recursos criados durante esse teste serão descartados no final do teste. ## Exemplo: criar um caso de teste personalizado **Example** O módulo de teste baixado no projeto GDK consiste em um recurso de amostra e um arquivo de implementação de etapas. No exemplo a seguir, criamos um arquivo de atributo para testar o atributo de implantação do objeto do software Greengrass. Testamos parcialmente a funcionalidade desse atributo com um cenário que executa a implantação de um componente por meio da Nuvem AWS do Greengrass. Esta é uma série de etapas que nos ajudam a entender as interações e os resultados esperados deste caso de uso. 1. **Criar um arquivo de atributos** Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. É possível encontrar uma amostra `component.feature` que parece com o exemplo a seguir. Nesse arquivo de recurso, você pode testar o recurso de implantação do software Greengrass. Você pode testar parcialmente a funcionalidade desse recurso com um cenário que executa uma implantação de um componente por meio da nuvem do Greengrass. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados desse caso de uso. ``` 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 ``` O GTF contém as definições de etapas de todas as etapas a seguir, exceto a etapa chamada: `And I call my custom step`. 1. **Implementar definições de etapas** O JAR autônomo GTF contém as definições de todas as etapas, exceto uma: `And I call my custom step`. Você pode implementar essa etapa no módulo de teste. Navegue até o código-fonte do arquivo de teste. É possível vincular sua etapa personalizada usando uma definição de etapa usando o comando a seguir. ``` @And("I call my custom step") public void customStep() { System.out.println("My custom step was called "); } ``` # Tutorial: usar um teste de confiança do conjunto de testes de confiança AWS IoT Greengrass O Testing Framework (GTF) e o Greengrass Development Kit (GDK) oferecem aos desenvolvedores maneiras de executar testes. end-to-end Você pode concluir este tutorial para inicializar um projeto do GDK com um componente, inicializar um projeto do GDK com um módulo de end-to-end teste e usar um teste de confiança do conjunto de testes de confiança. Depois de criar seu caso de teste personalizado, você poderá executar o teste. Um teste de confiança é um teste genérico fornecido pelo Greengrass que valida os comportamentos dos componentes fundamentais. Esses testes podem ser modificados ou estendidos para atender às necessidades mais específicas dos componentes. Para este tutorial, usaremos um HelloWorld componente. Se você estiver usando outro componente, substitua o HelloWorld componente pelo seu componente. Neste tutorial, você faz o seguinte: 1. Inicialize um projeto do GDK com um componente. 1. Inicialize um projeto GDK com um módulo de end-to-end teste. 1. Use um teste do conjunto de testes de confiança. 1. Adicione uma tag ao novo caso de teste. 1. Crie o JAR de teste. 1. Execute o teste do . **Topics** + [Pré-requisitos](#confidence-tests-tutorial-prerequisites) + [Etapa 1: inicializar um projeto do GDK com um componente](#init-gdk-with-component) + [Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste](#init-gdk-with-e2e-test) + [Etapa 3: usar um teste do conjunto de testes de confiança](#confidence-tests-tutorial-instructions) + [Etapa 4: adicionar uma tag ao novo caso de teste](#add-tag-to-test-case) + [Etapa 5: compilar o JAR de teste](#build-test-jar) + [Etapa 6: executar o teste](#run-test-gtf) + [Exemplo: usar um teste de confiança](#build-confidence-test-case-example) ## Pré-requisitos Para concluir este tutorial, você precisará do seguinte: + GDK versão 1.6.0 ou posterior + Java + Maven + Git ## Etapa 1: inicializar um projeto do GDK com um componente + Inicialize uma pasta vazia com um projeto do GDK. Faça download do componente `HelloWorld` implementado em Python executando o comando a seguir. ``` gdk component init -t HelloWorld -l python -n HelloWorld ``` Esse comando cria um diretório chamado `HelloWorld` no diretório atual. ## Etapa 2: inicializar um projeto do GDK com um end-to-end módulo de teste + O GDK permite que você baixe o modelo do módulo de teste que consiste em uma implementação de atributos e etapas. Execute o comando a seguir para abrir o diretório `HelloWorld` e inicializar o projeto GDK existente usando um módulo de teste. ``` cd HelloWorld gdk test-e2e init ``` Esse comando cria um diretório chamado `gg-e2e-tests` no diretório `HelloWorld`. Esse diretório de teste é um projeto [Maven](https://maven.apache.org/) que depende do JAR independente de testes do Greengrass. ## Etapa 3: usar um teste do conjunto de testes de confiança Escrever um caso de teste de confiança consiste em usar o arquivo de atributo fornecido e, se necessário, modificar os cenários. Para ver um exemplo de uso do teste de confiança, consulte [Exemplo: criar um caso de teste personalizado](run-e2e-tests-tutorial.md#build-test-case-example). Siga as etapas a seguir para usar um teste de confiança: + Use o arquivo de atributo fornecido. Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. Abra o arquivo `confidenceTest.feature` de amostra para usar o teste de confiança. ## Etapa 4: adicionar uma tag ao novo caso de teste + Você pode atribuir tags aos atributos e cenários para organizar o processo de teste. Você pode usar tags para categorizar os subconjuntos de cenários e também selecionar hooks condicionalmente para execução. Os atributos e os cenários podem ter várias tags separadas por um espaço. Neste exemplo, usamos o componente `HelloWorld`. Cada cenário é marcado com `@ConfidenceTest`. Altere ou adicione tags se quiser executar somente um subconjunto do conjunto de testes. Cada cenário de teste é descrito na parte superior de cada teste de confiança. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados de cada caso de teste. É possível estender esses testes adicionando suas próprias etapas ou modificando as existentes. ``` @ConfidenceTest Scenario: As a Developer, I can deploy GDK_COMPONENT_NAME to my device and see it is working as expected .... ``` ## Etapa 5: compilar o JAR de teste 1. Crie o componente. Você deve criar o componente antes de criar o módulo de teste. ``` gdk component build ``` 1. Crie o módulo de teste usando o comando a seguir. Esse comando criará o JAR de teste na pasta `greengrass-build`. ``` gdk test-e2e build ``` ## Etapa 6: executar o teste Quando você executa um teste de confiança, o GTF automatiza o ciclo de vida do teste, além de gerenciar os recursos que foram criados durante o teste. Primeiro, ele provisiona um dispositivo em teste (DUT) como uma AWS IoT coisa e instala o software principal do Greengrass nele. Em seguida, ele criará um novo componente chamado `HelloWorld` usando a fórmula especificada nesse caminho. O componente do `HelloWorld` é então implantado no dispositivo principal por meio de uma implantação da coisa do Greengrass. Em seguida, é verificado se a implantação foi bem-sucedida. O status da implantação será alterado para `COMPLETED` dentro de 3 minutos se a implantação for bem-sucedida. 1. Acesse o arquivo `gdk-config.json` no diretório do projeto para direcionar os testes com a tag `ConfidenceTest` ou qualquer tag que você especificou na etapa 4. Atualize a chave `test-e2e` usando o seguinte comando. ``` "test-e2e":{ "gtf_options" : { "tags":"ConfidenceTest" } } ``` 1. Antes de executar os testes, você deve fornecer AWS credenciais para o dispositivo host. O GTF usa essas credenciais para gerenciar os AWS recursos durante o processo de teste. Certifique-se de que o perfil fornecido tenha permissões para automatizar as operações necessárias incluídas no teste. Execute os comandos a seguir para fornecer as AWS credenciais. 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. Execute o teste usando o seguinte comando. ``` gdk test-e2e run ``` Esse comando baixa a versão mais recente do núcleo do Greengrass na pasta `greengrass-build` e executa testes usando-a. Esse comando também visa somente os cenários com a tag `ConfidenceTest` e gera um relatório para eles. Você verá que os AWS recursos criados durante esse teste serão descartados no final do teste. ## Exemplo: usar um teste de confiança **Example** O módulo de teste baixado no projeto do GDK consiste em um arquivo de atributo fornecido. No exemplo a seguir, usamos um arquivo de atributo para testar o atributo de implantação do objeto do software Greengrass. Testamos parcialmente a funcionalidade desse atributo com um cenário que executa a implantação de um componente por meio da Nuvem AWS do Greengrass. Esta é uma série de etapas que nos ajudam a entender as interações e os resultados esperados deste caso de uso. + **Use o arquivo de atributo fornecido.** Navegue até a pasta `gg-e2e-tests/src/main/resources/greengrass/features` no diretório atual. É possível encontrar uma amostra `confidenceTest.feature` que parece com o exemplo a seguir. ``` 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 ``` Cada cenário de teste é descrito na parte superior de cada teste de confiança. O cenário é uma série de etapas que ajudam a entender as interações e os resultados esperados de cada caso de teste. É possível estender esses testes adicionando suas próprias etapas ou modificando as existentes. Cada um dos cenários inclui comentários que ajudam a fazer esses ajustes.