DocumentaciónAEMTutoriales de AEMTutoriales de AEM as a Cloud Service

Prueba de un trabajador de Asset compute

Last update: Sun Jul 14 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Creado para:

  • Intermedio
  • Experimentado
  • Desarrollador

El proyecto de Asset compute define un patrón para crear y ejecutar fácilmente pruebas de Assets computes.

Anatomía de una prueba de trabajo

Las pruebas de los trabajadores de asset compute se dividen en grupos de pruebas y, dentro de cada grupo de pruebas, en uno o más casos de prueba que afirman una condición para probar.

La estructura de las pruebas en un proyecto de Asset compute es la siguiente:

/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 conversión de prueba puede tener los siguientes archivos:

  • file.<extension>

    • Archivo Source para probar (la extensión puede ser cualquier cosa excepto .link)
    • Requerido

  • rendition.<extension>

    • Representación esperada
    • Necesario, excepto para la prueba de errores

  • params.json

    • Las instrucciones JSON de una sola representación
    • Opcional

  • validate

    • Secuencia de comandos que obtiene rutas de acceso de archivos de representación esperadas y reales como argumentos y que debe devolver el código de salida 0 si el resultado es correcto, o un código de salida distinto de cero si la validación o comparación fallan.
    • Opcional, toma como valor predeterminado el comando diff
    • Use un script de shell que ajuste un comando de ejecución de docker para usar diferentes herramientas de validación

  • mock-<host-name>.json

Escritura de un caso de prueba

Este caso de prueba afirma que la entrada parametrizada (params.json) para el archivo de entrada (file.jpg) genera la representación PNG esperada (rendition.png).

  1. En primer lugar, elimine el caso de pruebas simple-worker generado automáticamente en /test/asset-compute/simple-worker, ya que no es válido, ya que el trabajador ya no copia el origen en la representación.

  2. Cree una nueva carpeta de caso de prueba en /test/asset-compute/worker/success-parameterized para probar una ejecución correcta del trabajador que genera una representación PNG.

  3. En la carpeta success-parameterized, agregue el archivo de entrada de prueba para este caso de prueba y asígnele el nombre file.jpg.

  4. En la carpeta success-parameterized, agregue un nuevo archivo denominado params.json que defina los parámetros de entrada del trabajador:

    code language-json 
    {
    "size": "400",
    "contrast": "0.25",
    "brightness": "-0.50"
}

    Son los mismos valores o claves pasados a la definición del perfil de Asset compute de la herramienta de desarrollo, menos la clave worker.

  5. Agregue el archivo de representación esperado a este caso de prueba y asígnele el nombre rendition.png. Este archivo representa la salida esperada del trabajador para la entrada dada file.jpg.

  6. Desde la línea de comandos, ejecute las pruebas en la raíz del proyecto ejecutando aio app test

    • Asegúrese de que Docker Desktop y las imágenes de Docker compatibles estén instalados e iniciados
    • Finalice cualquier instancia de la herramienta de desarrollo en ejecución

Prueba - Correcta

Escribir un caso de prueba de comprobación de errores

Este caso de prueba prueba prueba para asegurarse de que el trabajador genera el error apropiado cuando el parámetro contrast se establece en un valor no válido.

  1. Cree una nueva carpeta de casos de prueba en /test/asset-compute/worker/error-contrast para probar una ejecución errónea del trabajador debido a un valor de parámetro contrast no válido.

  2. En la carpeta error-contrast, agregue el archivo de entrada de prueba para este caso de prueba y asígnele el nombre file.jpg. El contenido de este archivo no es relevante para esta prueba. Solo necesita existir para superar la comprobación de "Origen dañado", para alcanzar las comprobaciones de validez de rendition.instructions que valida este caso de prueba.

  3. En la carpeta error-contrast, agregue un nuevo archivo denominado params.json que defina los parámetros de entrada del trabajador con el contenido:

    code language-json 
    {
    "contrast": "10",
    "errorReason": "rendition_instructions_error"
}
    • Establezca contrast parámetros en 10, un valor no válido, ya que el contraste debe estar entre -1 y 1, para arrojar un RenditionInstructionsError.
    • Afirmar que el error apropiado se produce en las pruebas estableciendo la clave errorReason en el "motivo" asociado con el error esperado. Este parámetro de contraste no válido genera el error personalizado, RenditionInstructionsError, por lo que se establece el errorReason en el motivo de este error, o rendition_instructions_error para afirmar que se ha producido.

  4. Dado que no se debe generar ninguna representación durante una ejecución errónea, no es necesario ningún archivo de rendition.<extension>.

  5. Ejecute el grupo de pruebas desde la raíz del proyecto ejecutando el comando aio app test

    • Asegúrese de que Docker Desktop y las imágenes de Docker compatibles estén instalados e iniciados
    • Finalice cualquier instancia de la herramienta de desarrollo en ejecución

Prueba - Contraste del error

Casos de prueba en Github

Los casos de prueba finales están disponibles en Github en:

Resolución de problemas

recommendation-more-help
4859a77c-7971-4ac9-8f5c-4260823c6f69