Test d’un Asset compute Worker

Le projet Asset compute définit un modèle permettant de créer et d’exécuter facilement des tests des agents d’Asset compute.

Anatomie d’un test de travail

Les tests des agents d’Asset compute sont divisés en suites de tests et, dans chaque suite de tests, un ou plusieurs cas de test affirmant une condition à tester.

La structure des tests dans un projet d’Asset compute est la suivante :

/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
            ...

Chaque test peut comporter les fichiers suivants :

  • file.<extension>
    • Fichier source à tester (l’extension peut être tout sauf .link)
    • Requis
  • rendition.<extension>
    • Rendu attendu
    • Obligatoire, à l’exception des tests d’erreur
  • params.json
    • Instructions JSON sur le rendu unique
    • Facultatif
  • validate
    • Script qui récupère les chemins d’accès aux fichiers de rendu prévus et réels sous forme d’arguments et qui doit renvoyer le code de sortie 0 si le résultat est correct, ou un code de sortie non nul si la validation ou la comparaison a échoué.
    • Facultatif, la commande diff est utilisée par défaut.
    • Utilisez un script shell qui encapsule une commande docker run pour utiliser différents outils de validation.
  • mock-<host-name>.json

Ecriture d’un cas de test

Ce cas de test affirme que l’entrée paramétrée (params.json) pour le fichier d’entrée (file.jpg) génère le rendu PNG attendu (rendition.png).

  1. Supprimez d’abord le cas de tests simple-worker générés automatiquement à l’adresse /test/asset-compute/simple-worker, car il n’est pas valide, car notre programme de travail ne copie plus simplement la source dans le rendu.

  2. Créez un dossier de cas de test à l’adresse /test/asset-compute/worker/success-parameterized pour tester une exécution réussie du programme de travail qui génère un rendu PNG.

  3. Dans le dossier success-parameterized , ajoutez le fichier d’entrée test pour ce cas de test et nommez-le file.jpg.

  4. Dans le dossier success-parameterized , ajoutez un nouveau fichier nommé params.json qui définit les paramètres d’entrée du programme de travail :

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

    Il s’agit des mêmes clés/valeurs transmises dans la définition de profil d’Asset compute 🔗 de l’outil de développement, moins la clé worker.

  5. Ajoutez le fichier de rendu attendu à ce cas de test et nommez-le rendition.png. Ce fichier représente la sortie attendue du programme de travail pour l’entrée file.jpg donnée.

  6. Sur la ligne de commande, exécutez le test de la racine du projet en exécutant aio app test

    • Vérifiez que Docker Desktop et les images Docker prises en charge sont installées et démarrées.
    • Arrêtez toutes les instances de l’outil de développement en cours d’exécution.

Test - Réussite

Ecriture d’un cas de test de vérification d’erreur

Ce cas de test teste afin de s’assurer que le programme de travail renvoie l’erreur appropriée lorsque le paramètre contrast est défini sur une valeur non valide.

  1. Créez un nouveau dossier de cas de test à l’adresse /test/asset-compute/worker/error-contrast pour tester une exécution erronée du programme de travail en raison d’une valeur de paramètre contrast non valide.

  2. Dans le dossier error-contrast , ajoutez le fichier d’entrée test pour ce cas de test et nommez-le file.jpg. Le contenu de ce fichier n'est pas important pour ce test, il doit simplement exister pour passer la vérification "Source corrompue", afin d'atteindre les rendition.instructions vérifications de validité, que ce cas de test valide.

  3. Dans le dossier error-contrast , ajoutez un nouveau fichier nommé params.json qui définit les paramètres d’entrée du programme de travail avec le contenu :

    {
        "contrast": "10",
        "errorReason": "rendition_instructions_error"
    }
    
    • Définissez les paramètres contrast sur 10, une valeur non valide, car le contraste doit être compris entre -1 et 1, pour générer une valeur RenditionInstructionsError.
    • Vérifiez que l’erreur appropriée est générée dans les tests en définissant la clé errorReason sur la "raison" associée à l’erreur attendue. Ce paramètre de contraste non valide renvoie l’erreur personnalisée, RenditionInstructionsError, et définit donc la errorReason sur la raison de cette erreur, ou rendition_instructions_error pour affirmer qu’elle est générée.
  4. Comme aucun rendu ne doit être généré lors d’une exécution erronée, aucun fichier rendition.<extension> n’est nécessaire.

  5. Exécutez la suite de tests à partir de la racine du projet en exécutant la commande aio app test

    • Vérifiez que Docker Desktop et les images Docker prises en charge sont installées et démarrées.
    • Arrêtez toutes les instances de l’outil de développement en cours d’exécution.

Test - Contraste d’erreur

Cas de test sur Github

Les derniers cas de test sont disponibles sur Github à l’adresse :

Résolution des problèmes

Sur cette page