Testar e depurar um aplicativo personalizado

Executar testes de unidade para um aplicativo personalizado

Instale o Docker Desktop no computador. 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 do aplicativo Asset compute no projeto, conforme descrito abaixo. Ela é conectada por meio de uma configuração no arquivo package.json. Também é possível ter testes de unidade JavaScript, como Jest. aio app test O executa ambos.

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

Estrutura de teste da unidade de aplicação

A estrutura de teste da unidade de aplicativo do Asset compute permite testar aplicativos sem gravar nenhum código. Ele depende do princípio de arquivo de origem para representação 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 para igualdade de bytes. Além disso, os serviços HTTP externos podem ser facilmente monitorados usando arquivos JSON simples.

Adicionar testes

Os testes são esperados dentro da pasta test no nível raiz do projeto Adobe I/O. 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 exemplo de aplicativos personalizados para obter alguns exemplos. Veja abaixo uma referência detalhada.

Testar saída

A saída de teste detalhada, incluindo os logs do aplicativo personalizado, é disponibilizada na pasta build na raiz do aplicativo Firefly, conforme demonstrado na saída aio app test.

Mover serviços externos

É possível fazer o mock das chamadas de serviço externo em suas ações definindo arquivos mock-<HOST_NAME>.json em seus casos de teste, onde HOST_NAME é o host que você deseja fazer o mock. Um exemplo de caso de uso é um aplicativo que faz uma chamada separada para S3. A nova estrutura de teste seria assim:

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 modelar, defina vários arquivos mock-<mocked-host>.json. Abaixo está um exemplo de arquivo de amostra 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 mock file para o serviço Wikimedia com o qual ele interage.

Compartilhar arquivos em casos de teste

É recomendável usar links simbólicos relativos se você compartilhar scripts file.*, params.json ou validate em vários testes. Eles são compatíveis com git. Certifique-se de dar 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

Testar erros esperados

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

OBSERVAÇÃO

Se um caso de teste não contiver um arquivo rendition.* esperado e não definir o errorReason esperado dentro do arquivo params.json, presume-se que seja um caso de erro com qualquer errorReason.

Estrutura do caso de teste de erro:

<error_test_case>/
    file.jpg
    params.json

Arquivo de parâmetro com motivo de erro:

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

Consulte a lista completa e a descrição dos motivos de erro de Asset compute.

Depurar um aplicativo personalizado

As etapas a seguir mostram como você pode depurar seu aplicativo personalizado usando o Código do Visual Studio. Ele permite ver registros ao vivo, pontos de interrupção de ocorrência e passar pelo código, bem como recarregar ao vivo as alterações do código local em cada ativação.

Muitas dessas etapas geralmente são automatizadas por aio prontas para uso, consulte a seção Depuração do aplicativo na documentação do Firefly. Por enquanto, as etapas abaixo incluem uma solução alternativa.

  1. Instale o mais recente wskdebug do GitHub e o ngrok opcional.

    npm install -g @openwhisk/wskdebug
    npm install -g ngrok --unsafe-perm=true
    
  2. Adicionar ao arquivo JSON das configurações do usuário. Ele continua usando o antigo depurador de código VS, o novo tem alguns problemas com o wskdebug: "debug.javascript.usePreview": false.

  3. Feche todas as instâncias de aplicativos abertas por aio app run.

  4. Implante o código mais recente usando aio app deploy.

  5. Execute somente o Asset compute Devtool usando aio asset-compute devtool. Mantenha aberto.

  6. No Editor de código VS, adicione a seguinte configuração de depuração ao launch.json:

    {
      "type": "node",
      "request": "launch",
      "name": "wskdebug worker",
      "runtimeExecutable": "wskdebug",
      "args": [
        "PROJECT-0.0.1/__secured_worker",           // Replace this with your ACTION NAME
        "${workspaceFolder}/actions/worker/index.js",
        "-l",
        "--ngrok"
      ],
      "localRoot": "${workspaceFolder}",
      "remoteRoot": "/code",
      "outputCapture": "std",
      "timeout": 30000
    }
    

    Busque o ACTION NAME da saída de aio app deploy.

  7. Selecione wskdebug worker na configuração de execução/depuração e pressione o ícone de reprodução. Aguarde até que ele inicie até que exiba Pronto para ativações na janela Debug Console.

  8. Clique em executar no Devtool. Você pode ver as ações executadas no editor de Código VS e os logs começam a ser exibidos.

  9. Defina um ponto de interrupção no seu código, execute novamente e ele deverá atingir.

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

OBSERVAÇÃO

Duas ativações estão presentes para cada solicitação em aplicativos personalizados. A primeira solicitação é uma ação da Web que se autochama de forma assíncrona no código do SDK. A segunda ativação é aquela que atinge seu código.

Nesta página