Testen und Debuggen eines benutzerdefinierten Programms test-debug-custom-worker

Ausführen von Komponententests für eine benutzerdefinierte Anwendung test-custom-worker

Installieren Sie Docker Desktop auf Ihrem Computer. Um eine benutzerdefinierte Sekundäranwendung (einen Worker) zu testen, führen Sie den folgenden Befehl im Stammverzeichnis der Anwendung aus:

$ aio app test

Dieser Befehl führt ein benutzerdefiniertes Komponententest-Framework für Asset Compute-Anwendungsaktionen im Projekt aus, wie unten beschrieben. Die Verbindung wird durch eine Konfiguration in der package.json-Datei hergestellt. Es ist auch möglich, JavaScript-Komponententests wie Jest durchzuführen. Mit aio app test wird beides ausgeführt.

Das Plug-in aio-cli-plugin-asset-compute ist als Entwicklungsabhängigkeit in die App der benutzerdefinierten Anwendung eingebettet, sodass es nicht auf Build-/Testsystemen installiert werden muss.

Test-Framework für Programmkomponenten unit-test-framework

Mit dem Asset Compute-Test-Framework für Anwendungskomponenten können Sie Anwendungen testen, ohne Code schreiben zu müssen. Es beruht auf dem Quell-zu-Ausgabedarstellungsdateiprinzip von Programmen. Es muss eine bestimmte Datei- und Ordnerstruktur eingerichtet werden, um Testfälle mit Testquelldateien, optionalen Parametern, erwarteten Ausgabedarstellungen und benutzerdefinierten Validierungsskripten zu definieren. Standardmäßig werden die Ausgabedarstellungen auf Byte-Gleichheit verglichen. Darüber hinaus können externe HTTP-Services mit einfachen JSON-Dateien einfach nachgeahmt werden.

Hinzufügen von Tests add-tests

Tests werden im Ordner test auf Stammebene des Projekts erwartet. Die Testfälle für jedes Programm sollten sich im Pfad test/asset-compute/<worker-name> befinden, wobei für jeden Testfall ein Ordner vorhanden sein muss:

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

Sehen Sie sich einige Beispiele für benutzerdefinierte Programme an. Nachstehend finden Sie eine ausführliche Referenz.

Testausgabe test-output

Das Verzeichnis build im Stammverzeichnis der Adobe Developer App Builder-App befinden sich die ausführlichen Testergebnisse und Protokolle der benutzerdefinierten Anwendung. Diese Details werden auch in der Ausgabe des Befehls aio app test angezeigt.

Nachahmen externer Services mock-external-services

Sie können externe Service-Aufrufe in Ihren Aktionen simulieren, indem Sie mock-<HOST_NAME>.json-Dateien für Ihre Testszenarien erstellen. HOST_NAME ist dabei der spezifische Host ist, der imitiert werden soll. Ein Anwendungsbeispiel wäre eine Anwendung, die S3 separat aufruft. Die neue Teststruktur würde folgendermaßen aussehen:

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

Die nachgeahmte Datei ist eine HTTP-Antwort im JSON-Format. Weitere Informationen finden Sie in dieser Dokumentation. Wenn mehrere Host-Namen nachgeahmt werden müssen, definieren Sie mehrere mock-<mocked-host>.json-Dateien. Im Folgenden finden Sie ein Beispiel einer nachgeahmten Datei für google.com mit dem Namen mock-google.com.json:

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

Das Beispiel worker-animal-pictures enthält eine Mock-Datei für den Wikimedia-Service, mit dem es interagiert.

Gemeinsames Nutzen von Dateien über Testfälle hinweg share-files-across-test-cases

Adobe empfiehlt, relative Symlinks zu verwenden, wenn Sie file.*-, params.json- oder validate-Skripte für mehrere Tests nutzen. Diese werden von Git unterstützt. Achten Sie darauf, Ihren gemeinsam genutzten Dateien einen eindeutigen Namen zu geben, da Sie möglicherweise verschiedene Dateien haben. Im folgenden Beispiel mischen und vergleichen die Tests einige gemeinsam genutzte und ihre eigenen Dateien:

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

Testen erwarteter Fehler test-unexpected-errors

Fehlertestfälle sollten keine erwartete rendition.*-Datei enthalten und den erwarteten errorReason in der params.json-Datei definieren.

Struktur von Fehlertestfällen:

<error_test_case>/
    file.jpg
    params.json

Parameterdatei mit Fehlerursache:

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

Sehen Sie sich dazu die vollständige Liste und Beschreibung der Asset Compute-Fehlerursachen an.

Debuggen eines benutzerdefinierten Programms debug-custom-worker

Die folgenden Schritte zeigen, wie Sie Ihr benutzerdefiniertes Programm mit Visual Studio Code debuggen können. Er ermöglicht die Anzeige von Live-Protokollen, das Auffinden von Haltepunkten und das Durchlaufen des Codes sowie das Live-Neuladen lokaler Code-Änderungen bei jeder Aktivierung.

Mit aio werden viele dieser Schritte standardmäßig automatisiert. Navigieren Sie zum Abschnitt „Debuggen der Anwendung“ in der Adobe Developer App Builder-Dokumentation. Die folgenden Schritte beinhalten vorerst eine Problemumgehung.

Alle Code-Änderungen werden in Echtzeit geladen und werden wirksam, sobald die nächste Aktivierung erfolgt.