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

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

Instalar Desktop Docker na sua máquina. Para testar um trabalhador personalizado, execute o seguinte comando na raiz do aplicativo:

$ aio app test

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

A variável aio-cli-plugin-asset-compute o plug-in é incorporado como dependência de desenvolvimento no aplicativo de aplicativo personalizado, de modo 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

Os testes são esperados dentro do test pasta no nível raiz da variável Adobe I/O 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

Veja exemplo de aplicativos personalizados para obter alguns exemplos. Abaixo está uma referência detalhada.

Saída de teste test-output

Os resultados detalhados do teste, incluindo os logs do aplicativo personalizado, são disponibilizados na build pasta na raiz do aplicativo Adobe Developer App Builder, conforme demonstrado na aio app test saída.

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

É possível simular chamadas de serviço externas em suas ações definindo mock-<HOST_NAME>.json em seus casos de teste, onde HOST_NAME é o host que você gostaria de simular. 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 a serem simulados, defina vários mock-<mocked-host>.json arquivos. Abaixo está um exemplo de arquivo modelo para google.com nomeado 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 fictício para o serviço Wikimedia com o qual interage.

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

É recomendável usar ligações simbólicas relativas se você compartilhar file.*, params.json ou validate scripts 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 valor esperado rendition.* arquivo e deve definir o valor esperado errorReason dentro do params.json arquivo.

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 a lista completa e a descrição de Motivos de erro de 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.

Muitas dessas etapas geralmente são automatizadas pelo aio pronto para uso, consulte a seção Depuração do aplicativo no Documentação do Construtor de aplicativos Adobe Developer. 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.