Test d'un Asset compute

Le projet d'Asset compute définit un modèle permettant de créer et d'exécuter facilement les tests des travailleurs de l'Asset compute.

Anatomie d’un test de travail

Les tests des travailleurs d’Asset compute sont divisés en suites de tests et, dans chaque suite de tests, un ou plusieurs cas de test qui affirment qu’une condition doit être testée.

La structure des essais 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 de rendu unique
    • Facultatif
  • validate
    • Script qui obtient les chemins d’accès au fichier de rendu réel et attendu en tant qu’arguments et qui doit renvoyer le code de sortie 0 si le résultat est ok, 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é automatiquement à /test/asset-compute/simple-worker, car il n’est pas valide, car notre collaborateur ne copie plus simplement la source dans le rendu.

  2. Créez un dossier de cas de test à l’emplacement /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 ](…/develop/development-tool.md) 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 travailleur pour l'entrée file.jpg donnée.

  6. Dans la ligne de commande, exécutez les tests 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êt de toute instance 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 est testé pour s'assurer que le programme de travail génère l'erreur appropriée lorsque le paramètre contrast est défini sur une valeur non valide.

  1. Créez un dossier de cas de test à l’emplacement /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 juste exister pour passer la vérification "source corrompue", afin d'atteindre les vérifications de validité rendition.instructions que cette cause 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 renvoyer une valeur RenditionInstructionsError.
    • Affirmer 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, par conséquent, définissez errorReason sur le motif de cette erreur ou rendition_instructions_error pour affirmer qu'elle est générée.
  4. Aucun rendu ne devant ê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êt de toute instance de l’outil de développement en cours d’exécution

Test - Contraste d’erreur

Tests de cas sur Github

Les derniers essais sont disponibles sur Github à l'adresse suivante :

Résolution des incidents

Sur cette page

Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free
Adobe Summit Banner

A virtual event April 27-28.

Expand your skills and get inspired.

Register for free