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
elle 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. 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 Adobe I/O. 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
Les résultats de test détaillés, y compris les journaux de l’application personnalisée, sont disponibles dans le dossier build situé à la racine de l’application Adobe Developer App Builder, comme le montre la sortie aio app test.
Simuler des services externes mock-external-services
Il est possible de simuler des appels de service externes dans vos actions en définissant des fichiers mock-<HOST_NAME>.json dans vos cas de test, HOST_NAME étant l’hôte que vous souhaitez simuler. 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
Il est recommandé 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.
rendition.* attendu et ne définit pas la valeur errorReason attendue dans le fichier params.json, il s’agit d’un cas d’erreur contenant une valeur errorReason quelconque.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.
La plupart de ces étapes sont généralement automatisées par aio prêt à l’emploi. Consultez la section Déboguer l’application dans la documentation d’Adobe Developer App Builder. Pour le moment, les étapes ci-dessous comportent une solution de contournement.
-
Installez la dernière version de wskdebug depuis GitHub et, facultativement, ngrok.
code language-shell npm install -g @openwhisk/wskdebug npm install -g ngrok --unsafe-perm=true -
Ajoutez à votre fichier JSON de paramètres utilisateur. Il continue à utiliser l’ancien débogueur VS Code, le nouveau a quelques problèmes avec wskdebug :
"debug.javascript.usePreview": false. -
Fermez toutes les instances d’applications ouvertes via
aio app run. -
Déployez le code le plus récent à l’aide de
aio app deploy. -
Exécutez uniquement l’outil Asset Compute Devtool avec
aio asset-compute devtool. Gardez-le ouvert. -
Dans VS Code Editor, ajoutez la configuration de débogage suivante à votre
launch.json:code language-json { "type": "node", "request": "launch", "name": "wskdebug worker", "runtimeExecutable": "wskdebug", "args": [ "PROJECT-0.0.1/__secured_worker", // Replace this with your ACTION NAME "${workspaceFolder}/actions/worker/index.js", "-l", "--ngrok" ], "localRoot": "${workspaceFolder}", "remoteRoot": "/code", "outputCapture": "std", "timeout": 30000 }Récupérez le
ACTION NAMEà partir de la sortie deaio app deploy. -
Sélectionnez
wskdebug workerdans la configuration d’exécution/de débogage et appuyez sur l’icône de lecture. Patientez jusqu’au démarrage et à l’affichage de la mention Prêt pour les activations dans la fenêtre Console de débogage. -
Cliquez sur Exécuter dans l’outil Devtool. Vous pouvez voir les actions s’exécuter dans l’éditeur VS Code et les journaux commencer à s’afficher.
-
Définissez un point d’arrêt dans votre code et lancez à nouveau l’exécution. Le point d’arrêt devrait ensuite être atteint.
Toutes les modifications de code sont chargées en temps réel et prennent effet dès que l’activation suivante se produit.