Tester et déboguer une application personnalisée test-debug-custom-worker

Exécuter des tests unitaires pour une application personnalisée test-custom-worker

Installez Docker Desktop sur votre ordinateur. Pour tester un programme de travail personnalisé, exécutez la commande suivante à la racine de l’application :

$ aio app test

Cette commande exécute un framework de test unitaire personnalisé pour les actions de l’application Asset Compute dans le projet comme décrit ci-dessous. Ce framework est connecté via une configuration dans le fichier package.json. Il est également possible d’effectuer des tests unitaires JavaScript tels que Jest. Le aio app test exécute les deux.

Le plug-in aio-cli-plugin-asset-compute est incorporé en tant que dépendance de développement dans l’application personnalisée pour qu’il ne soit pas nécessaire de l’installer sur les systèmes de création/test.

Framework de test unitaire d’application unit-test-framework

Le framework de test unitaire d’application Asset Compute permet de tester les applications sans écrire de code. Il repose sur le principe d’un fichier entre la source et le rendu pour les applications. Il est nécessaire de configurer une certaine structure de fichiers et de dossiers pour définir des cas de test avec des fichiers source de test, des paramètres facultatifs, des rendus attendus et des scripts de validation personnalisés. Par défaut, les rendus sont comparés pour l’égalité des octets. En outre, il est facile de simuler les services HTTP externes à l’aide de fichiers JSON simples.

Ajouter des tests add-tests

Les tests doivent être placés dans le dossier test au niveau racine du projet. Les cas de test pour chaque application doivent se trouver dans le chemin d’accès test/asset-compute/<worker-name>, avec un dossier pour chaque cas :

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

Consultez les exemples d’applications personnalisées pour en savoir plus. Vous trouverez ci-dessous une référence détaillée.

Tester la sortie test-output

Le répertoire build à la racine de l’application Adobe Developer App Builder héberge les résultats de test détaillés et les journaux de l’application personnalisée. Ces détails sont également affichés dans la sortie de la commande aio app test.

Simuler des services externes mock-external-services

Vous pouvez simuler des appels de service externes dans vos actions en créant des fichiers mock-<HOST_NAME>.json pour vos scénarios de test, HOST_NAME étant l’hôte spécifique que vous avez l’intention d’imiter. Un exemple d’utilisation est une application qui effectue un appel distinct à S3. La nouvelle structure de test pourrait ressembler à ceci :

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

Le fichier de simulation est une réponse http au format JSON. Pour plus d’informations, consultez cette documentation. S’il existe plusieurs noms d’hôte à simuler, définissez plusieurs fichiers mock-<mocked-host>.json. Un exemple de fichier de simulation de google.com nommé mock-google.com.json est proposé ci-dessous :

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

L’exemple worker-animal-pictures contient un fichier de simulation pour le service Wikimedia avec lequel il interagit.

Partager des fichiers pour les cas de test share-files-across-test-cases

Adobe recommande d’utiliser des liens symboliques relatifs si vous partagez des scripts file.*, params.json ou validate pour différents tests. Ils sont pris en charge avec Git. Veillez à attribuer un nom unique à vos fichiers partagés, car vous pouvez en avoir plusieurs. Dans l’exemple ci-dessous, les tests combinent quelques fichiers partagés, et les leurs :

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

Tester les erreurs attendues test-unexpected-errors

Les cas de tests d’erreur ne doivent pas contenir de fichier rendition.* attendu et ont à définir la valeur errorReason attendue dans le fichier params.json.

Structure des cas de tests d’erreur :

<error_test_case>/
    file.jpg
    params.json

Fichier de paramètres avec la raison de l’erreur :

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

Voir la liste complète et la description des raisons des erreurs d’Asset Compute.

Déboguer une application personnalisée debug-custom-worker

Les étapes ci-dessous montrent comment déboguer votre application personnalisée à l’aide de Visual Studio Code. Il permet d’afficher les journaux en direct, d’atteindre des points d’arrêt, de parcourir le code, mais aussi de charger à nouveau en direct des modifications du code local à chaque activation.

L’élément aio prêt à l’emploi automatise la plupart de ces étapes. Accédez à la section Débogage de l’application dans la documentation Adobe Developer App Builder. Pour le moment, les étapes ci-dessous comportent une solution de contournement.

Toutes les modifications de code sont chargées en temps réel et prennent effet dès que l’activation suivante se produit.