O teste da interface personalizada é um recurso opcional que permite criar e executar automaticamente testes da interface do usuário para seus aplicativos.
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.
O Adobe recomenda seguir a estrutura e a linguagem (JavaScript e WDIO) fornecidas na AEM Arquétipo de projeto.
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
arquivo do submódulo de testes da interface do usuário.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>
[...]
Se o seu projeto não incluir essa linha, será necessário editar o arquivo para aceitar o teste da interface do usuário.
O arquivo pode conter uma linha avisando para não editá-lo. Isso se deve ao fato de ele ter sido introduzido em seu projeto antes que o teste de interface de usuário de opt-in fosse introduzido e os clientes não queriam editar o arquivo. Isso pode ser ignorado com segurança.
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.
O Arquétipo de projeto AEM O pode gerar um projeto de Testes de interface do usuário para que você não tenha requisitos especiais para a linguagem de programação.
Para gerar um contexto de compilação do Docker, você precisa de um módulo Maven que:
Dockerfile
e qualquer outro arquivo necessário para criar a imagem Docker com seus testes.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.
Dockerfile
, obrigatório para criar a imagem Dockerwait-for-grid.sh
, cujos objetivos são descritos abaixotest-module
pastaO 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.
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.
As variáveis de ambiente a seguir serão passadas para a imagem Docker em tempo de execução.
Variável | Exemplos | Descrição |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
O 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 |
O URL da instância do autor do AEM |
AEM_AUTHOR_USERNAME |
admin |
O nome de usuário para fazer logon na instância do autor do AEM |
AEM_AUTHOR_PASSWORD |
admin |
A senha para fazer logon na instância do autor do AEM |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
O URL da instância de publicação de 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 |
O 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
variável de ambiente.Quando o endpoint de status do Selenium responde com uma resposta positiva, os testes podem ser iniciados.
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.
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.
UPLOAD_URL
variável de ambiente.
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
.200 OK
resposta do tipo text/plain
.
<input>
elemento para testar os uploads do arquivo em seu aplicativo.