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.
O AEM fornece um conjunto integrado de quality gates (portais de qualidade) do Cloud Manager para garantir atualizações tranquilas para aplicativos personalizados. Em especial, os portais de teste de TI já promovem a criação e a automação de testes personalizados usando as APIs do AEM.
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). Além disso, um projeto de testes de interface do usuário pode ser facilmente gerado usando o Arquétipo de Projetos AEM.
Os testes de interface do usuário são executados como parte de um quality gate (portal de qualidade) específico para cada pipeline do Cloud Manager com uma etapa dedicada de Teste de interface do usuário personalizado. 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 de 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 Compilação de testes de interface do usuário.
A Adobe recomenda seguir a estrutura e a linguagem (JavaScript e WDIO) fornecidas no Arquétipo de Projetos AEM.
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.
testing.properties
.ui-tests.version=1
.pom.xml
do submódulo de testes de interface do usuário.tar.gz
.A compilação dos testes de interface do usuário será ignorada se esse arquivo não estiver presente.
Para incluir um arquivo testing.properties
no artefato de compilação, adicione a instrução include
no arquivo assembly-ui-test-docker-context.xml
.
[...]
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
<include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]
Se o seu projeto não incluir essa linha, será necessário editar o arquivo para aderir ao teste de interface do usuário.
O arquivo pode conter uma linha aconselhando a não editá-la. Isso se deve ao fato de ele ter sido introduzido em seu projeto antes da adesão ao teste de interface do usuário e que os clientes não devem editar o arquivo. Pode ser ignorado com segurança.
Um projeto Maven gera um contexto de compilação do Docker. Este contexto de compilação do Docker descreve como criar uma imagem do Docker contendo testes de interface do usuário, que o Cloud Manager usa para gerar uma imagem do Docker contendo os testes de interface do usuário reais.
Esta seção descreve as etapas necessárias para adicionar um projeto de testes de interface do usuário ao seu repositório.
O Arquétipo de Projetos AEM pode gerar um projeto de testes de interface do usuário para que você não tenha requisitos especiais quanto à linguagem de programação.
Para gerar um contexto de compilação do Docker, você precisará de um módulo Maven que:
Dockerfile
e qualquer outro arquivo necessário para criar a imagem do Docker em seus testes.ui-test-docker-context
.A maneira mais simples de fazer isso é configurar o Plug-in de compilação do Maven para criar o arquivo de contexto de compilação do Docker e atribuir o classificador correto a ele.
Você pode compilar testes de interface do usuário com diferentes tecnologias e estruturas, mas esta seção presume que o projeto seja apresentado de uma maneira semelhante à descrita a seguir.
├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│ ├── package.json
│ ├── index.js
│ └── wdio.conf.js
└── wait-for-grid.sh
O arquivo pom.xml
controla a compilação Maven. Adicione uma execução ao Plug-in de compilação do Maven semelhante ao mostrado a seguir.
<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 compilação Maven a criar um arquivo com base nas instruções contidas em assembly-ui-test-docker-context.xml
, chamado de descritor de compilação no jargão do plug-in. O descritor de compilação lista todos os arquivos que devem fazer parte do arquivamento.
<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 compilação instrui o plug-in a criar um arquivamento do tipo .tar.gz
e atribuir o classificador ui-test-docker-context
a ele. Além disso, ele lista os arquivos que devem ser incluídos no arquivamento, incluindo os descritos a seguir.
Dockerfile
, obrigatório para criar a imagem do Dockerwait-for-grid.sh
, cujos objetivos são descritos abaixotest-module
O descritor de compilação também exclui alguns arquivos que podem ser gerados durante a execução local dos testes de interface do usuário. Isso garante que um arquivo menor seja gerado, e consequentemente, resulta em compilações mais rápidas.
O arquivamento que contém o contexto de compilação do Docker é selecionado automaticamente pelo Cloud Manager, que criará a imagem do Docker contendo seus testes durante os pipelines de implantação. Eventualmente, o Cloud Manager executará a imagem do Docker para executar os testes de interface do usuário em seu aplicativo.
A compilação deve produzir zero ou um arquivamento. Se produzir zero arquivamento, a etapa de teste será aprovada por padrão. Se a compilação produzir mais de um arquivamento, o arquivamento selecionado será não determinístico.
Esta seção descreve as convenções que a imagem do Docker que contém seus testes de interface do usuário deve seguir. A imagem do Docker é criada a partir do contexto de compilação do Docker descrito na seção anterior.
As variáveis de ambiente a seguir serão passadas para a imagem do Docker no tempo de execução.
Variável | Exemplos | Descrição |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
A URL do servidor Selenium |
SELENIUM_BROWSER |
chrome |
A implementação do navegador usada pelo servidor Selenium |
AEM_AUTHOR_URL |
http://my-ip:4502/context-path |
A URL da instância do autor do AEM |
AEM_AUTHOR_USERNAME |
admin |
O nome de usuário para fazer logon na instância de autoria do AEM |
AEM_AUTHOR_PASSWORD |
admin |
A senha para fazer logon na instância de autoria do AEM |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
A URL da instância de publicação do AEM |
AEM_PUBLISH_USERNAME |
admin |
O nome de usuário para fazer logon na instância de publicação do AEM |
AEM_PUBLISH_PASSWORD |
admin |
A senha para fazer logon na instância de publicação do AEM |
REPORTS_PATH |
/usr/src/app/reports |
O caminho onde o relatório XML dos resultados do teste deve ser salvo |
UPLOAD_URL |
http://upload-host:9090/upload |
A URL onde o arquivo deve ser carregado para torná-lo acessível ao Selenium |
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.
SELENIUM_BASE_URL
.Quando o endpoint de status do Selenium responder com uma resposta positiva, os testes poderão ser iniciados.
A imagem do Docker deve gerar relatórios de teste no formato XML JUnit e salvá-los no caminho especificado pela variável de ambiente REPORTS_PATH
. O formato XML JUnit é um formato amplamente usado para relatar resultados de testes. Se a imagem do Docker usar Java e Maven, os módulos de teste padrão, como o Plug-in Maven Surefire e o Plug-in Maven Failsafe poderão gerar os relatórios imediatamente.
Se a imagem do Docker for implementada com outras linguagens de programação ou executores de teste, verifique a documentação das ferramentas escolhidas para saber como gerar relatórios XML JUnit.
A imagem Docker pode gerar saídas de teste adicionais (por exemplo, capturas de tela, vídeos) e salvá-las no caminho especificado pela variável de ambiente REPORTS_PATH
. Qualquer arquivo encontrado abaixo de REPORTS_PATH
está incluído no arquivo de resultados de teste.
Se um arquivo de resultados de teste tiver sido criado durante uma execução de teste da interface, o arquivo de log de teste conterá no final uma referência ao local do arquivo de resultados de teste.
[...]
===============================================================
The detailed test results can be downloaded from the URL below.
Note: the link will expire after 60 days
https://results-host/test-results.zip
===============================================================
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 de um ativo diretamente no Selenium. Em vez disso, o upload de um arquivo exige as etapas descritas a seguir.
UPLOAD_URL
.
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
.200 OK
do tipo text/plain
.
<input>
para testar os uploads de arquivo em seu aplicativo.