Testar um trabalhador do Asset Compute

O projeto do Asset Compute define um padrão para criar e executar facilmente testes de trabalhadores do Asset Compute.

Anatomia de um teste de trabalhador

Os testes dos trabalhadores do Asset Compute são divididos em conjuntos de testes e, em cada conjunto de testes, um ou mais casos de teste que afirmam uma condição para testar.

A estrutura de testes em um projeto do Asset Compute é a seguinte:

/actions/<worker-name>/index.js
...
/test/
  asset-compute/
    <worker-name>/           <--- Test suite for the worker, must match the yaml key for this worker in manifest.yml
        <test-case-1>/       <--- Specific test case 
            file.jpg         <--- Input file (ie. `source.path` or `source.url`)
            params.json      <--- Parameters (ie. `rendition.instructions`)
            rendition.png    <--- Expected output file (ie. `rendition.path`)
        <test-case-2>/       <--- Another specific test case for this worker
            ...

Cada conversão de teste pode ter os seguintes arquivos:

file.<extension>
- Arquivo de origem a ser testado (a extensão pode ser qualquer item exceto .link)
- Obrigatório
rendition.<extension>
- Representação esperada
- Obrigatório, exceto para teste de erro
params.json
- As instruções JSON de representação única
- Opcional
validate
- Um script que obtém caminhos de arquivo de renderização esperados e reais como argumentos e deve retornar o código de saída 0 se o resultado for ok, ou um código de saída diferente de zero se a validação ou comparação falhar.
- Opcional, o padrão é o comando diff
- Use um script de shell que envolva um comando docker run para usar ferramentas de validação diferentes
mock-<host-name>.json
- Respostas HTTP JSON formatadas para zombando de chamadas de serviço externas.
- Opcional, somente usado se o código de trabalho fizer solicitações HTTP próprias

Gravando um caso de teste

Esse caso de teste afirma a entrada parametrizada (params.json) para o arquivo de entrada (file.jpg) que gera a renderização PNG esperada (rendition.png).

Primeiro, exclua o caso de testes simple-worker gerado automaticamente em /test/asset-compute/simple-worker, pois isso é inválido, pois nosso trabalhador não copia mais simplesmente a fonte para a representação.
Crie uma nova pasta de caso de teste em /test/asset-compute/worker/success-parameterized para testar uma execução bem-sucedida do trabalhador que gera uma representação PNG.
Na pasta success-parameterized, adicione o arquivo de entrada de teste para esse caso de teste e o nomeie como file.jpg.
Na pasta success-parameterized, adicione um novo arquivo chamado params.json que defina os parâmetros de entrada do trabalhador:
```
{ 
    "size": "400",
    "contrast": "0.25",
    "brightness": "-0.50"
}
```
Esses são os mesmos valores/chaves transmitidos na definição de perfil do Asset Compute da Ferramenta de desenvolvimento, menos a chave worker.
Adicione o arquivo de representação esperado a esse caso de teste e o nomeie como rendition.png. Este arquivo representa a saída esperada do trabalhador para a entrada file.jpg fornecida.
Na linha de comando, execute os testes na raiz do projeto executando aio app test
- Certifique-se de que o Docker Desktop e as imagens Docker de suporte estão instaladas e iniciadas
- Encerrar qualquer instância da Ferramenta de desenvolvimento em execução

Teste - Sucesso

Gravando um caso de teste de verificação de erro

Este caso de teste testa para garantir que o trabalhador jogue o erro apropriado quando o parâmetro contrast estiver definido como um valor inválido.

Crie uma nova pasta de caso de teste em /test/asset-compute/worker/error-contrast para testar uma execução incorreta do trabalhador devido a um valor de parâmetro contrast inválido.
Na pasta error-contrast, adicione o arquivo de entrada de teste para esse caso de teste e o nomeie como file.jpg. O conteúdo desse arquivo é irrelevante para esse teste, basta existir para passar da verificação "Origem corrompida", para alcançar as rendition.instructions verificações de validade, que esse caso de teste valida.
Na pasta error-contrast, adicione um novo arquivo chamado params.json que defina os parâmetros de entrada do trabalhador com o conteúdo:
```
{
    "contrast": "10",
    "errorReason": "rendition_instructions_error"
}
```
- Defina os parâmetros contrast como 10, um valor inválido, como o contraste deve estar entre -1 e 1, para acionar um RenditionInstructionsError.
- Repare que o erro apropriado é lançado nos testes definindo a chave errorReason para o "motivo" associado ao erro esperado. Esse parâmetro de contraste inválido lança o erro personalizado, RenditionInstructionsError, portanto, defina o errorReason para o motivo deste erro, ourendition_instructions_error para afirmar que ele é lançado.
Como nenhuma representação deve ser gerada durante uma execução de erro, nenhum arquivo rendition.<extension> é necessário.
Execute o conjunto de teste a partir da raiz do projeto executando o comando aio app test
- Certifique-se de que o Docker Desktop e as imagens Docker de suporte estão instaladas e iniciadas
- Encerrar qualquer instância da Ferramenta de desenvolvimento em execução