Prueba de un trabajador de Asset compute
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
- Archivo Source para probar (la extensión puede ser cualquier cosa excepto
-
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
- Respuestas HTTP con formato JSON para burlar llamadas de servicio externas.
- Opcional, sólo se utiliza si el código de trabajo realiza sus propias solicitudes HTTP
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
).
-
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. -
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. -
En la carpeta
success-parameterized
, agregue el archivo de entrada de prueba para este caso de prueba y asígnele el nombrefile.jpg
. -
En la carpeta
success-parameterized
, agregue un nuevo archivo denominadoparams.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
. -
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 dadafile.jpg
. -
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
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.
-
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ámetrocontrast
no válido. -
En la carpeta
error-contrast
, agregue el archivo de entrada de prueba para este caso de prueba y asígnele el nombrefile.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 derendition.instructions
que valida este caso de prueba. -
En la carpeta
error-contrast
, agregue un nuevo archivo denominadoparams.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 en10
, un valor no válido, ya que el contraste debe estar entre -1 y 1, para arrojar unRenditionInstructionsError
. - 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 elerrorReason
en el motivo de este error, orendition_instructions_error
para afirmar que se ha producido.
- Establezca
-
Dado que no se debe generar ninguna representación durante una ejecución errónea, no es necesario ningún archivo de
rendition.<extension>
. -
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
Casos de prueba en Github
Los casos de prueba finales están disponibles en Github en: