Prueba y depuración de una aplicación personalizada test-debug-custom-worker

Ejecutar pruebas unitarias para una aplicación personalizada test-custom-worker

Instale Docker Desktop en su equipo. Para probar un trabajador personalizado, ejecute el siguiente comando en la raíz de la aplicación:

$ aio app test

Este comando ejecuta un marco de prueba unitario personalizado para las acciones de la aplicación de Asset compute en el proyecto como se describe a continuación. Se conectó a través de una configuración en el archivo package.json. También es posible tener pruebas unitarias de JavaScript como Jest. El aio app test ejecuta ambos.

El complemento aio-cli-plugin-asset-compute está incrustado como una dependencia de desarrollo en la aplicación de aplicación personalizada, de modo que no es necesario instalarlo en sistemas de compilación o prueba.

Marco de prueba unitario de aplicación unit-test-framework

El marco de pruebas unitarias de la aplicación de Asset compute permite probar aplicaciones sin escribir código. Se basa en el principio del archivo de origen a representación de las aplicaciones. Se debe configurar una estructura de archivos y carpetas determinada para definir casos de prueba con archivos de origen de prueba, parámetros opcionales, representaciones esperadas y scripts de validación personalizados. De forma predeterminada, las representaciones se comparan para la igualdad de bytes. Además, los servicios HTTP externos se pueden burlar fácilmente mediante archivos JSON simples.

Agregar pruebas add-tests

Se esperan pruebas dentro de la carpeta test en el nivel raíz del proyecto. Los casos de prueba para cada aplicación deben estar en la ruta de acceso test/asset-compute/<worker-name>, con una carpeta para cada caso de prueba:

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

Eche un vistazo a aplicaciones personalizadas de ejemplo para ver algunos ejemplos. A continuación se muestra una referencia detallada.

Resultado de prueba test-output

El directorio build en la raíz de la aplicación de Adobe Developer App Builder contiene los resultados detallados de las pruebas y los registros de la aplicación personalizada. Estos detalles también se muestran en la salida del comando aio app test.

Burlar servicios externos mock-external-services

Puede simular llamadas de servicio externas dentro de sus acciones creando mock-<HOST_NAME>.json archivos para sus escenarios de prueba, con HOST_NAME como el host específico que desea imitar. Un ejemplo de caso de uso es una aplicación que realiza una llamada independiente a S3. La nueva estructura de prueba tendría este aspecto:

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

El archivo de prueba es una respuesta http con formato JSON. Para obtener más información, consulte esta documentación. Si hay varios nombres de host para burlar, defina varios archivos mock-<mocked-host>.json. A continuación se muestra un ejemplo de archivo de simulación para google.com con el nombre mock-google.com.json:

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

El ejemplo worker-animal-pictures contiene un archivo de prueba para el servicio Wikimedia con el que interactúa.

Uso compartido de archivos entre casos de prueba share-files-across-test-cases

El Adobe recomienda utilizar enlaces simbólicos relativos si comparte scripts de file.*, params.json o validate en varias pruebas. Son compatibles con Git. Asegúrese de asignar un nombre único a los archivos compartidos, ya que es posible que tenga otros distintos. En el ejemplo siguiente, las pruebas mezclan y hacen coincidir algunos archivos compartidos, y los suyos propios:

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

Prueba de errores esperados test-unexpected-errors

Los casos de pruebas de error no deben contener un archivo rendition.* esperado y deben definir el errorReason esperado dentro del archivo params.json.

Estructura de caso de prueba de error:

<error_test_case>/
    file.jpg
    params.json

Archivo de parámetros con motivo del error:

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

Ver una lista completa y una descripción de razones de error de Asset compute.

Depuración de una aplicación personalizada debug-custom-worker

Los pasos siguientes muestran cómo se puede depurar una aplicación personalizada mediante Visual Studio Code. Permite ver registros en directo, puntos de interrupción de visitas y paso a paso por el código, así como la recarga en directo de los cambios del código local en cada activación.

aio automatiza muchos de estos pasos de forma predeterminada. Vaya a la sección Depuración de la aplicación en Adobe Developer App Builder documentation. Por ahora, los pasos siguientes incluyen una solución.

Los cambios de código se cargan en tiempo real y son efectivos en cuanto se produce la siguiente activación.