Teste de interface do usuário ui-testing

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.

Visão geral custom-ui-testing

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 são compactados em uma imagem do Docker para permitir uma variedade de opções de idiomas e estruturas (como Cypress, Selenium, Java e Maven, além do JavaScript). Além disso, um projeto de testes de interface pode ser facilmente gerado usando o Arquétipo de Projetos AEM.

A Adobe incentiva o uso do Cypress, pois oferece recarregamento em tempo real e espera automática, o que ajuda a economizar tempo e melhorar a produtividade durante os testes. O Cypress também fornece uma sintaxe simples e intuitiva, facilitando a aprendizagem e o uso, mesmo para usuários novatos em testes.

Os testes de interface do usuário são executados como um quality gate (portal de qualidade) na etapa Custom UI Testing (Teste de interface do usuário personalizado) - necessário em pipelines de produção, opcional em pipelines de não produção. Quaisquer testes de interface, 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. Os testes podem ser escritos em qualquer idioma, desde que sigam as convenções definidas na seção Compilação de Testes de Interface do Usuário.

Introdução aos testes de interface get-started-ui-tests

Esta seção descreve as etapas necessárias para a configuração dos testes de interface para execução no Cloud Manager.

Compilação de testes de interface do usuário building-ui-tests

Um projeto Maven gera um contexto de compilação do Docker. Este contexto de construção do Docker descreve como criar uma imagem do Docker que contenha os testes de interface, que o Cloud Manager usa para gerar uma imagem do Docker contendo os testes de interface reais.

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

Gerar um contexto de compilação do Docker generate-docker-build-context

Para gerar um contexto de construção do Docker, você precisará de um módulo Maven que:

A maneira mais simples é 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 o seguinte:

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 Cloud Manager seleciona automaticamente o arquivo de contexto de compilação do Docker e cria a imagem de teste durante os pipelines de implantação. Por fim, a Cloud Manager executa 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.

Adesão do cliente customer-opt-in

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

A compilação e a execução dos testes de interface 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 estiver usando os exemplos fornecidos pela Adobe:

Gravação de testes da interface do usuário writing-ui-tests

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.

Variáveis de ambiente environment-variables

As seguintes variáveis de ambiente são passadas para a imagem do Docker em tempo de execução, dependendo da estrutura.

* these values will be empty if there is no publish instance

Os exemplos de teste da Adobe fornecem funções auxiliares para acessar os parâmetros de configuração:

Cypress: use a função padrão Cypress.env('VARIABLE_NAME')

Gerar relatórios de teste generate-test-reports

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.

Pré-requisitos prerequisites

Detalhes específicos do Selenium

Aguardar o Selenium estar pronto waiting-for-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.

Quando o endpoint de status do Selenium responder com uma resposta positiva, os testes poderão ser iniciados.

As amostras de teste da interface do usuário da Adobe usam wait-for-grid.sh. Ele é executado na inicialização do Docker e inicia testes somente depois que a grade está pronta.

Capturar imagens de tela e vídeos capture-screenshots

A imagem do Docker pode gerar saídas de teste adicionais (por exemplo, capturas de tela ou vídeos) e salvá-las no caminho especificado pela variável de ambiente REPORTS_PATH. Qualquer arquivo encontrado abaixo de REPORTS_PATH é incluído no arquivo de resultados de teste.

Os exemplos de teste fornecidos pela Adobe criam, por padrão, capturas de tela de qualquer teste com falha.

Você pode usar as funções auxiliares para criar capturas de tela nos testes.

Se um arquivo de resultados de teste for criado durante uma execução de teste da interface, você poderá baixá-lo da Cloud Manager clicando no botão Download Details na etapa Teste da interface personalizado.

Fazer upload de arquivos upload-files

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.

Detalhes específicos do Cypress

Configurar proxy HTTP

O ponto de entrada do contêiner Docker precisa verificar o valor da variável de ambiente PROXY_HOST.

Se esse valor estiver vazio, nenhuma etapa adicional será necessária e os testes deverão ser executados sem usar um proxy HTTP.

Se não estiver vazio, o script de ponto de entrada precisa:

Um exemplo de implementação pode ser encontrado no ponto de entrada do módulo de teste de amostra Cypress em GitHub.

Detalhes específicos do dramaturgo

Configurar proxy HTTP

Semelhante ao Cypress, os testes precisam usar o proxy HTTP se uma variável de ambiente PROXY_HOST não vazia for fornecida.

Nesse caso, as seguintes edições precisam ser feitas.

Dockerfile

Instalar cURL e libnss3-tools, que fornece certutil.

RUN apt -y update \
    && apt -y --no-install-recommends install curl libnss3-tools \
    && rm -rf /var/lib/apt/lists/*

Script de ponto de entrada

Inclua um script bash que, caso a variável de ambiente PROXY_HOST seja fornecida, faça o seguinte:

Exemplo de implementação:

# setup proxy environment variables and CA certificate
if [ -n "${PROXY_HOST:-}" ]; then
  if [ -n "${PROXY_HTTPS_PORT:-}" ]; then
    export HTTP_PROXY="https://${PROXY_HOST}:${PROXY_HTTPS_PORT}"
  elif [ -n "${PROXY_HTTP_PORT:-}" ]; then
    export HTTP_PROXY="http://${PROXY_HOST}:${PROXY_HTTP_PORT}"
  fi
  if [ -n "${PROXY_CA_PATH:-}" ]; then
    echo "installing certificate"
    mkdir -p $HOME/.pki/nssdb
    certutil -d sql:$HOME/.pki/nssdb -A -t "CT,c,c" -n "EaaS Client Proxy Root" -i $PROXY_CA_PATH
    export NODE_EXTRA_CA_CERTS=${PROXY_CA_PATH}
  fi
  if [ -n "${PROXY_OBSERVABILITY_PORT:-}" ] && [ -n "${HTTP_PROXY:-}" ]; then
    echo "waiting for proxy"
    curl --silent  --retry ${PROXY_RETRY_ATTEMPTS:-3} --retry-connrefused --retry-delay ${PROXY_RETRY_DELAY:-10} \
      --proxy ${HTTP_PROXY} --proxy-cacert ${PROXY_CA_PATH:-""} \
      ${PROXY_HOST}:${PROXY_OBSERVABILITY_PORT}
    if [ $? -ne 0 ]; then
      echo "proxy is not ready"
      exit 1
    fi
  fi
fi

Configuração do dramaturgo

Modifique a configuração do playwright (por exemplo, em playwright.config.js) para usar um proxy caso a variável de ambiente HTTP_PROXY esteja definida.

Exemplo de implementação:

const proxyServer = process.env.HTTP_PROXY || ''

// enable proxy if set
if (proxyServer !== '') {
 cfg.use.proxy = {
  server: proxyServer,
 }
}

Execução de testes locais de interface run-ui-tests-locally

Antes de ativar testes de interface em um pipeline do Cloud Manager, a Adobe recomenda que você execute os testes de interface localmente no AEM as a Cloud Service SDK. Ou execute em uma instância real do AEM as a Cloud Service.

Exemplo de teste do Cypress cypress-sample

Exemplo de teste do JavaScript WebdriverIO javascript-sample

Amostra de teste do dramaturgo playwright-sample

Exemplo de teste do Java Selenium WebDriver java-sample