Teste da interface

O teste da interface personalizada é um recurso opcional que permite criar e executar automaticamente testes da interface do usuário para seus aplicativos.

Visão geral

AEM fornece um conjunto integrado de Portas de qualidade do Cloud Manager para garantir atualizações tranquilas para aplicativos personalizados. Em particular, o teste de TI já promove a criação e automação de testes personalizados usando APIs AEM.

Os testes da interface do usuário são testes baseados em Selenium, compactados em uma imagem Docker, para permitir uma grande escolha na linguagem e estruturas (como Java e Maven, Node e WebDriver.io, ou qualquer outra estrutura e tecnologia criada no Selenium). Além disso, um projeto de testes da interface do usuário pode ser facilmente gerado usando o Arquétipo de projeto AEM.

Os testes da interface do usuário são executados como parte de uma porta de qualidade específica para cada pipeline do Cloud Manager com um dedicado Teste de interface personalizada etapa. Quaisquer testes de interface do usuário, incluindo regressão e novas funcionalidades, permitem que erros sejam detectados e relatados.

Diferentemente dos testes funcionais personalizados, que são testes HTTP escritos em Java, os testes da interface do usuário podem ser uma imagem do Docker com testes escritos em qualquer idioma, desde que sigam as convenções definidas na seção Criação de testes da interface do usuário.

Opt-in do cliente

Para que o Cloud Manager crie e execute seus testes de interface do usuário, é necessário aderir a esse recurso adicionando um arquivo ao repositório.

• O nome do arquivo deve ser testing.properties.
• O conteúdo do arquivo deve ser ui-tests.version=1.
• O arquivo deve estar sob o submódulo maven para testes de interface do usuário ao lado do pom.xml arquivo do submódulo de testes da interface do usuário.
• O arquivo deve estar na raiz da build tar.gz arquivo.

A build dos testes da interface do usuário será ignorada se esse arquivo não estiver presente.

Para incluir uma testing.properties no artefato de criação, adicione um include na instrução assembly-ui-test-docker-context.xml arquivo.

[...]
<includes>
    <include>Dockerfile</include>
    <include>wait-for-grid.sh</include>
    <include>testing.properties</include> <!- opt-in test module in Cloud Manager -->
</includes>
[...]

Criação de testes da interface do usuário

Um projeto Maven gera um contexto de compilação Docker. Este contexto de compilação do Docker descreve como criar uma imagem Docker contendo os testes da interface do usuário, que os usuários do Cloud Manager geram uma imagem Docker contendo os testes da interface do usuário real.

Esta seção descreve as etapas necessárias para adicionar um projeto de testes de interface ao seu repositório.

Gerar um Contexto de Criação do Docker

Para gerar um contexto de compilação do Docker, você precisa de um módulo Maven que:

• Produz um arquivo que contém um Dockerfile e qualquer outro arquivo necessário para criar a imagem Docker com seus testes.
• Marca o arquivo com a variável ui-test-docker-context classificador.

A maneira mais simples de fazer isso é configurar a variável Plug-in de Montagem Maven para criar o arquivo de contexto de compilação do Docker e atribuir o classificador correto a ele.

Você pode criar testes de interface do usuário com diferentes tecnologias e estruturas, mas esta seção presume que o projeto foi apresentado de uma maneira semelhante ao seguinte.

├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│   ├── package.json
│   ├── index.js
│   └── wdio.conf.js
└── wait-for-grid.sh

O pom.xml O arquivo cuida da build Maven. Adicione uma execução ao Plug-in Maven Assembly semelhante ao seguinte.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-assembly-plugin</artifactId>
    <configuration>
        <descriptors>
            <descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
        </descriptors>
        <tarLongFileMode>gnu</tarLongFileMode>
    </configuration>
    <executions>
        <execution>
            <id>make-assembly</id>
            <phase>package</phase>
            <goals>
                <goal>single</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Esta execução instrui o Plug-in de Montagem Maven a criar um arquivo com base nas instruções contidas no assembly-ui-test-docker-context.xml, chamada de descritor de assembly no jargão do plug-in. O descritor de assembly lista todos os arquivos que devem fazer parte do arquivo.

<assembly>
    <id>ui-test-docker-context</id>
    <includeBaseDirectory>false</includeBaseDirectory>
    <formats>
        <format>tar.gz</format>
    </formats>
    <fileSets>
        <fileSet>
            <directory>${basedir}</directory>
            <includes>
                <include>Dockerfile</include>
                <include>wait-for-grid.sh</include>
            </includes>
        </fileSet>
        <fileSet>
            <directory>${basedir}/test-module</directory>
            <excludes>
                <exclude>node/**</exclude>
                <exclude>node_modules/**</exclude>
                <exclude>reports/**</exclude>
            </excludes>
        </fileSet>
    </fileSets>
</assembly>

O descritor de assembly instrui o plug-in a criar um arquivo do tipo .tar.gz e atribui o ui-test-docker-context classificador nele. Além disso, ele lista os arquivos que devem ser incluídos no arquivo, incluindo o seguinte.

• A Dockerfile, obrigatório para criar a imagem Docker
• O wait-for-grid.sh , cujos objetivos são descritos abaixo
• Os testes reais da interface do usuário, implementados por um projeto Node.js no test-module pasta

O descritor de conjunto também exclui alguns arquivos que podem ser gerados durante a execução local dos testes da interface do usuário. Isso garante um arquivo menor e builds mais rápidas.

O arquivo que contém o contexto de compilação do Docker é automaticamente selecionado pelo Cloud Manager, que criará a imagem do Docker que contém seus testes durante seus pipelines de implantação. Eventualmente, o Cloud Manager executará a imagem do Docker para executar os testes da interface de usuário em seu aplicativo.

A build deve produzir zero ou um arquivo. Se produzir zero arquivos, a etapa de teste passará por padrão. Se a build produzir mais de um arquivo, qual arquivo está selecionado é não determinístico.

Gravação de testes da interface do usuário

Esta seção descreve as convenções que a imagem do Docker que contém seus testes de interface de usuário devem seguir. A imagem do Docker é criada a partir do contexto de compilação do Docker descrito na seção anterior.

Variáveis de ambiente

As variáveis de ambiente a seguir serão passadas para a imagem Docker em tempo de execução.

Aguardando o Selenium estar pronto

Antes de os testes começarem, é responsabilidade da imagem do Docker garantir que o servidor Selenium esteja funcionando. Aguardar o serviço Selenium é um processo de duas etapas.

1. Leia o URL do serviço Selenium no SELENIUM_BASE_URL variável de ambiente.
2. Pesquisa em intervalos regulares para a ponto final de status exposto pela API do Selenium.

Quando o endpoint de status do Selenium responde com uma resposta positiva, os testes podem ser iniciados.

Gerar relatórios de teste

A imagem Docker deve gerar relatórios de teste no formato JUnit XML e salvá-los no caminho especificado pela variável de ambiente REPORTS_PATH. O formato JUnit XML é um formato amplamente usado para relatar os resultados de testes. Se a imagem do Docker usar Java e Maven, módulos de teste padrão como Plug-in do Maven Surefire e Plug-in Maven Failsafe podem gerar esses relatórios imediatamente.

Se a imagem do Docker for implementada com outras linguagens de programação ou corredores de teste, verifique a documentação das ferramentas escolhidas para saber como gerar relatórios XML JUnit.

Fazer upload de arquivos

Os testes às vezes devem carregar arquivos no aplicativo que está sendo testado. Para manter a implantação do Selenium flexível em relação aos testes, não é possível fazer upload direto de um ativo para o Selenium. Em vez disso, o upload de um arquivo requer as seguintes etapas.

1. Faça upload do arquivo no URL especificado pela variável UPLOAD_URL variável de ambiente.
   • O upload deve ser executado em uma solicitação de POST com um formulário multipart.
   • O formulário multipart deve ter um único campo de arquivo.
   • É equivalente a curl -X POST ${UPLOAD_URL} -F "data=@file.txt".
   • Consulte a documentação e as bibliotecas da linguagem de programação usada na imagem do Docker para saber como executar tal solicitação HTTP.
2. Se o upload for bem-sucedido, a solicitação retornará um 200 OK resposta do tipo text/plain.
   • O conteúdo da resposta é um identificador de arquivo opaco.
   • Você pode usar esse identificador no lugar de um caminho de arquivo em um <input> elemento para testar os uploads do arquivo em seu aplicativo.