Testen und Debuggen eines benutzerdefinierten Programms

Ausführen von Komponententests für ein benutzerdefiniertes Programm

Installieren Sie Docker Desktop auf Ihrem Computer. Um ein benutzerdefiniertes Sekundärprogramm zu testen, führen Sie den folgenden Befehl im Stammverzeichnis des Programms aus:

$ aio app test

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

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

Test-Framework für Programmkomponenten

Mit dem Asset Compute-Test-Framework für Programmkomponenten können Sie Programme testen, ohne Code schreiben zu müssen. Es beruht auf dem Quell-zu-Ausgabedarstellungsdateiprinzip von Programmen. Eine bestimmte Datei- und Ordnerstruktur muss 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

Tests werden im test-Ordner auf der Stammebene des Adobe I/O-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

Die detaillierte Testausgabe einschließlich der Protokolle des benutzerdefinierten Programms wird im build-Ordner im Stammverzeichnis der Firefly-App bereitgestellt, wie in der Ausgabe aio app test gezeigt.

Nachahmen externer Services

Es ist möglich, externe Service-Aufrufe in Ihren Aktionen nachzuahmen, indem Sie mock-<HOST_NAME>.json-Dateien in Ihren Testfällen definieren, wobei HOST_NAME der Host ist, den Sie nachahmen möchten. Ein Anwendungsbeispiel ist ein Programm, das 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 nachgeahmte Datei für den Wikimedia-Service, mit dem es interagiert.

Gemeinsames Nutzen von Dateien über Testfälle hinweg

Es wird empfohlen, relative Symlinks zu verwenden, wenn Sie file.*-, params.json- oder validate-Skripte über mehrere Tests hinweg gemeinsam 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

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

HINWEIS

Wenn ein Testfall keine erwartete rendition.*-Datei enthält und nicht den erwarteten errorReason in der params.json-Datei definiert, wird davon ausgegangen, dass es sich um einen Fehlerfall mit einem beliebigen errorReason handelt.

Struktur von Fehlertestfällen:

<error_test_case>/
    file.jpg
    params.json

Parameterdatei mit Fehlerursache:

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

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

Debuggen eines benutzerdefinierten Programms

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.

Viele dieser Schritte werden in der Regel von aio standardmäßig automatisiert. Weitere Informationen finden Sie im Abschnitt zum Debuggen eines Programms in der Firefly-Dokumentation. Die folgenden Schritte beinhalten vorerst eine Problemumgehung.

  1. Installieren Sie die neuste Version von wskdebug und optional ngrok von GitHub.

    npm install -g @openwhisk/wskdebug
    npm install -g ngrok --unsafe-perm=true
    
  2. Fügen Sie Folgendes zu Ihrer JSON-Datei mit den Benutzereinstellungen hinzu. Damit wird weiterhin der alte VS-Code-Debugger verwendet, da der neue einige Probleme mit wskdebug hat: "debug.javascript.usePreview": false.

  3. Schließen Sie alle Instanzen von Apps, die über aio app run geöffnet sind.

  4. Stellen Sie den neuesten Code mit aio app deploy bereit.

  5. Führen Sie nur das Asset Compute-Entwickler-Tool mit aio asset-compute devtool aus. Lassen Sie es geöffnet.

  6. Fügen Sie im VS-Code-Editor die folgende Debug-Konfiguration zu Ihrer launch.json hinzu:

    {
      "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
    }
    

    Rufen Sie den ACTION NAME aus der Ausgabe von aio app deploy ab.

  7. Wählen Sie wskdebug worker in der Ausführungs-/Debug-Konfiguration aus und klicken Sie auf das Wiedergabesymbol. Warten Sie auf den Start, bis die Meldung Ready for activations im Fenster der Debug Console angezeigt wird.

  8. Klicken Sie im Entwickler-Tool auf Run. Sie können die im VS Code-Editor ausgeführten Aktionen sehen und die Protokolle werden angezeigt.

  9. Legen Sie einen Haltepunkt im Code fest und führen Sie den Code erneut aus. Der Haltepunkt sollte wirksam werden.

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

HINWEIS

In benutzerdefinierten Programmen sind für jede Anfrage zwei Aktivierungen vorhanden. Die erste Anfrage ist eine Web-Aktion, die sich im SDK-Code asynchron aufruft. Die zweite Aktivierung verwendet Ihren Code.

Auf dieser Seite