Testar e depurar um aplicativo personalizado test-debug-custom-worker

Executar testes de unidade para um aplicativo personalizado test-custom-worker

Instale o Docker Desktop no computador. Para testar um trabalhador personalizado, execute o seguinte comando na raiz do aplicativo:

$ aio app test

Este comando executa uma estrutura de teste de unidade personalizada para ações de aplicativo do Asset Compute no projeto, conforme descrito abaixo. Ele é conectado por uma configuração no arquivo package.json. Também é possível ter testes de unidade do JavaScript, como o Jest. O aio app test executa ambos.

O plug-in aio-cli-plugin-asset-compute está incorporado como uma dependência de desenvolvimento no aplicativo de aplicativo personalizado para que não precise ser instalado em sistemas de compilação/teste.

Estrutura de teste da unidade de aplicativos unit-test-framework

A estrutura de teste da unidade de aplicativo do Asset Compute permite testar aplicativos sem gravar nenhum código. Depende do princípio de origem para representação de arquivos de aplicativos. Uma determinada estrutura de arquivos e pastas deve ser configurada para definir casos de teste com arquivos de origem de teste, parâmetros opcionais, representações esperadas e scripts de validação personalizados. Por padrão, as representações são comparadas em relação à igualdade de bytes. Além disso, os serviços HTTP externos podem ser facilmente ridicularizados usando arquivos JSON simples.

Adicionar testes add-tests

Testes são esperados dentro da pasta test no nível raiz do projeto. Os casos de teste para cada aplicativo devem estar no caminho test/asset-compute/<worker-name>, com uma pasta para cada caso de teste:

action/
manifest.yml
package.json
...
test/
  asset-compute/
    <worker-name>/
        <testcase1>/
            file.jpg
            params.json
            rendition.png
        <testcase2>/
            file.jpg
            params.json
            rendition.gif
            validate
        <testcase3>/
            file.jpg
            params.json
            rendition.png
            mock-adobe.com.json
            mock-console.adobe.io.json

Consulte os exemplos de aplicativos personalizados para ver alguns exemplos. Abaixo está uma referência detalhada.

Saída de teste test-output

O diretório build na raiz do aplicativo Adobe Developer App Builder hospeda os resultados e logs de teste detalhados do aplicativo personalizado. Esses detalhes também são exibidos na saída do comando aio app test.

Serviços externos fictícios mock-external-services

Você pode simular chamadas de serviço externas em suas ações criando mock-<HOST_NAME>.json arquivos para seus cenários de teste, sendo HOST_NAME o host específico que você pretende imitar. Um exemplo de caso de uso é um aplicativo que faz uma chamada separada para S3. A nova estrutura de teste seria semelhante a:

test/
  asset-compute/
    <worker-name>/
      <testcase3>/
        file.jpg
        params.json
        rendition.png
        mock-<HOST_NAME1>.json
        mock-<HOST_NAME2>.json

O arquivo modelo é uma resposta http formatada em JSON. Para obter mais informações, consulte esta documentação. Se houver vários nomes de host para simular, defina vários mock-<mocked-host>.json arquivos. Abaixo está um exemplo de arquivo de modelo para google.com chamado mock-google.com.json:

[{
    "httpRequest": {
        "path": "/images/hello.txt"
        "method": "GET"
    },
    "httpResponse": {
        "statusCode": 200,
        "body": {
          "message": "hello world!"
        }
    }
}]

O exemplo worker-animal-pictures contém um arquivo modelo para o serviço Wikimedia com o qual ele interage.

Compartilhar arquivos entre casos de teste share-files-across-test-cases

A Adobe recomenda o uso de symlinks relativos se você compartilhar scripts file.*, params.json ou validate em vários testes. Eles são compatíveis com o Git. Atribua um nome exclusivo aos arquivos compartilhados, pois você pode ter arquivos diferentes. No exemplo abaixo, os testes estão misturando e correspondendo a alguns arquivos compartilhados e seus próprios:

tests/
    file-one.jpg
    params-resize.json
    params-crop.json
    validate-image-compare

    jpg-png-resize/
        file.jpg    - symlink: ../file-one.jpg
        params.json - symlink: ../params-resize.json
        rendition.png
        validate    - symlink: ../validate-image-compare

    jpg2-png-crop/
        file.jpg
        params.json - symlink: ../params-crop.json
        rendition.gif
        validate    - symlink: ../validate-image-compare

    jpg-gif-crop/
        file.jpg    - symlink: ../file-one.jpg
        params.json - symlink: ../params-crop.json
        rendition.gif
        validate

Erros esperados do teste test-unexpected-errors

Os casos de testes de erro não devem conter um arquivo esperado rendition.* e devem definir o esperado errorReason dentro do arquivo params.json.

Estrutura de caso de teste de erro:

<error_test_case>/
    file.jpg
    params.json

Arquivo de parâmetros com motivo do erro:

{
    "errorReason": "SourceUnsupported",
    // ... other params
}

Veja uma lista completa e uma descrição dos motivos de erro do Asset compute.

Depurar um aplicativo personalizado debug-custom-worker

As etapas a seguir mostram como você pode depurar seu aplicativo personalizado usando o Visual Studio Code. Ele permite a visualização de logs em tempo real, pontos de interrupção de ocorrência e código de passo a passo, bem como o recarregamento em tempo real de alterações de código local em cada ativação.

O aio pronto para uso automatiza muitas dessas etapas. Vá para a seção Depuração do Aplicativo na documentação do Adobe Developer App Builder. Por enquanto, as etapas abaixo incluem uma solução alternativa.

Quaisquer alterações de código são carregadas em tempo real e entram em vigor assim que ocorrer a próxima ativação.