Teste funcional

Saiba mais sobre os três diferentes tipos de testes funcionais integrados ao processo de implantação do AEM as a Cloud Service para garantir a qualidade e a confiabilidade do seu código.

Visão geral

Existem três tipos diferentes de testes funcionais no AEM as a Cloud Service.

Para todos os testes funcionais, os resultados detalhados dos testes podem ser baixados como um arquivo .zip usando o botão Baixar log de compilação na tela de visão geral da compilação como parte do processo de implantação.

Esses logs não incluem os logs do processo de tempo de execução real do AEM. Para acessá-los, consulte o documento Acesso e gerenciamento de logs para obter mais detalhes.

Tanto os testes funcionais do produto quanto os testes funcionais personalizados de amostra se baseiam nos Clientes de teste do AEM.

Teste funcional do produto

Os testes funcionais do produto são um conjunto de testes estáveis de integração HTTP (ITs) com funcionalidade principal no AEM, como tarefas de autoria e replicação. Esses testes são mantidos pela Adobe e têm como objetivo impedir a implantação de alterações no código de aplicativo personalizado, caso interrompa as funcionalidades principais.

Os testes funcionais do produto são executados automaticamente sempre que um novo código é implantado no Cloud Manager e não podem ser ignorados.

Os testes funcionais do produto são mantidos como um projeto de código aberto. Consulte os testes funcionais do produto no GitHub para obter detalhes.

Teste funcional personalizado

Embora o teste funcional do produto seja definido pela Adobe, você pode criar seu próprio teste de qualidade para o seu aplicativo. Ele será executado como um teste funcional personalizado como parte do pipeline de produção para garantir a qualidade do seu aplicativo.

O teste funcional personalizado é executado tanto para implantações de código personalizado quanto para atualizações por push, o que torna especialmente importante criar bons testes funcionais que impeçam as alterações de quebrar o código do aplicativo. A etapa de teste funcional personalizado está sempre presente e não pode ser ignorada.

Gravação de testes funcionais personalizados

As mesmas ferramentas que a Adobe usa para gravar testes funcionais do produto podem ser usadas para gravar seus testes funcionais personalizados. Use os testes funcionais do produto no GitHub como exemplo para gravar seus testes.

O código do teste funcional personalizado é o código Java localizado na pasta it.tests do seu projeto. Ele deve produzir um único JAR com todos os testes funcionais. Se a compilação produzir mais de um JAR de teste, o JAR selecionado será não determinístico. Se produzir zero JAR de teste, a etapa de teste será aprovada por padrão. Consulte o Arquétipo de Projetos AEM para ver exemplos de testes.

Os testes são executados em uma infraestrutura de teste mantida pela Adobe, incluindo pelo menos duas instâncias de autoria, duas instâncias de publicação e uma configuração de dispatcher. Portanto, os testes funcionais personalizados são executados em relação a toda a pilha do AEM.

Os testes funcionais personalizados devem ser empacotados como um arquivo JAR separado produzido pela mesma compilação Maven que os artefatos a serem implantados no AEM. Geralmente, é um módulo Maven separado. O arquivo JAR resultante deve conter todas as dependências necessárias e geralmente é criado usando o maven-assembly-plugin com o descritor jar-with-dependencies.

Além disso, o JAR deve ter a o cabeçalho de manifesto Cloud-Manager-TestType definido como integration-test.

O código a seguir é um exemplo de configuração de maven-assembly-plugin.

<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

Neste arquivo JAR, os nomes de classe dos testes reais a serem executados devem terminar em IT.

Por exemplo, uma classe chamada com.myco.tests.aem.it.ExampleIT seria executada, mas uma chamada com.myco.tests.aem.it.ExampleTest não.

Além disso, para excluir o código de teste da verificação de abrangência da verificação de código, o código de teste deve estar abaixo de um pacote chamado it (o filtro de exclusão de abrangência é **/it/**/*.java).

As classes de teste precisam ser testes JUnit normais. A infraestrutura de teste é projetada e configurada para ser compatível com as convenções usadas pela biblioteca de testes aem-testing-clients. Os desenvolvedores são altamente incentivados a usar essa biblioteca e seguir suas práticas recomendadas.

Consulte o aem-testing-clients repositório GitHub para obter mais detalhes.

DICA

Assista a este vídeo sobre como você pode usar testes funcionais personalizados para melhorar a confiança nos seus pipelines de CI/CD.

Testes de interface do usuário personalizados

Os testes de interface do usuário personalizados são um recurso opcional que permite criar e executar automaticamente testes na interface do usuário para seus aplicativos. Os testes de interface do usuário são testes baseados em Selenium, compactados em uma imagem do Docker, para permitir uma variedade de opções de linguagens e estruturas (como Java e Maven, Node e WebDriver.io, ou qualquer outra estrutura e tecnologia criada no Selenium).

Consulte o documento Testes de interface do usuário personalizados para obter mais detalhes.

Execução local de testes

Como as classes de teste são testes JUnit, elas podem ser executadas a partir das principais IDEs Java, como Eclipse, IntelliJ, NetBeans, entre outras. Como os testes funcionais do produto e os testes funcionais personalizados se baseiam na mesma tecnologia, ambos podem ser executados localmente copiando os testes de produto aos seus testes personalizados.

No entanto, ao executá-los, será necessário definir uma variedade de propriedades do sistema esperadas pela biblioteca aem-testing-clients (e os Clientes de teste Sling subjacentes).

As propriedades do sistema são mostradas a seguir.

  • sling.it.instances - should be set to 2
  • sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
  • sling.it.instance.runmode.1 - should be set to author
  • sling.it.instance.adminUser.1 - should be set to the author admin user, for example, admin
  • sling.it.instance.adminPassword.1 - should be set to the author admin password
  • sling.it.instance.url.2 - should be set to the publish URL, for example, http://localhost:4503
  • sling.it.instance.runmode.2 - should be set to publish
  • sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
  • sling.it.instance.adminPassword.2 - should be set to the publish admin password

Nesta página