カスタムアプリケーションのテストとデバッグ test-debug-custom-worker

カスタムアプリケーションのユニットテストの実行 test-custom-worker

Docker Desktop をコンピューターにインストールします。 カスタムワーカーをテストするには、アプリケーションのルートで次のコマンドを実行します。

$ aio app test

このコマンドにより、以下で説明するように、プロジェクト内の Asset Compute アプリケーションアクションに対してカスタムユニットテストフレームワークが実行されます。 これは package.json ファイル内の設定を通じて接続されます。 また、Jest などの JavaScript ユニットテストをおこなうこともできます。 aio app test は、両方を実行します。

aio-cli-plugin-asset-compute プラグインは、カスタムアプリケーションアプリに開発依存関係として埋め込まれているので、ビルド／テストシステムにインストールする必要はありません。

アプリケーションユニットテストフレームワーク unit-test-framework

Asset Compute アプリケーションユニットテストフレームワークを使用すると、コードを記述することなく、アプリケーションをテストできます。 アプリケーションのソースからレンディションへのファイル原則を利用します。 テストソースファイル、オプションパラメーター、予想されるレンディション、カスタム検証スクリプトを含むテストケースを定義するには、特定のファイルおよびフォルダー構造を設定する必要があります。 デフォルトでは、レンディションのバイト等価性が比較されます。 さらに、単純な JSON ファイルを使用して外部 HTTP サービスのモックを容易に作成できます。

テストの追加 add-tests

テストは、プロジェクトのルートレベルにある test フォルダー内で行われることが想定されます。 各アプリケーションのテストケースは、パス test/asset-compute/<worker-name> 内にテストケースごとに 1 つのフォルダーとして配置する必要があります。

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

いくつかの例については、カスタムアプリケーションの例を参照してください。 以下に詳細を説明します。

テスト出力 test-output

Adobe Developer App Builder アプリのルートにある build ディレクトリには、カスタムアプリケーションの詳細なテスト結果とログが格納されます。 また、これらの詳細は、aio app test コマンドの出力にも表示されます。

モック用外部サービス mock-external-services

テストシナリオ用の mock-<HOST_NAME>.json ファイルを作成し、HOST_NAME を模倣する特定のホストにすれば、アクション内で外部サービス呼び出しをシミュレートできます。 ユースケースの例として、S3 への個別の呼び出しを行うアプリケーションが挙げられます。 新しいテスト構造は次のようになります。

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

モックファイルは、JSON 形式の http 応答です。 詳しくは、こちらのドキュメントを参照してください。 モック作成対象のホスト名が複数ある場合は、複数の mock-<mocked-host>.json ファイルを定義します。 以下は、mock-google.com.json という名前の、google.com のサンプルモックファイルです。

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

サンプル worker-animal-pictures には、やり取りするウィキメディアサービスのモックファイルが含まれます。

テストケース間でのファイルの共有 share-files-across-test-cases

file.*、params.json または validate スクリプトを複数のテスト間で共有する場合は、相対シンボリックリンクを使用することをお勧めします。 これらは Git でサポートされます。 共有ファイルには異なる名前をつけることもあるので、必ず一意の名前を付けてください。 以下の例では、いくつかの共有ファイルとテスト自体のファイルを組み合わせています。

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

予期されるエラーのテスト test-unexpected-errors

エラーテストケースには、予期される rendition.* ファイルを含めず、予期される errorReason を params.json ファイル内で定義してください。

エラーテストケースの構造：

<error_test_case>/
    file.jpg
    params.json

エラー理由を含んだパラメーターファイル：

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

Asset Compute のエラー理由の完全なリストと説明を参照してください。

カスタムアプリケーションのデバッグ debug-custom-worker

次の手順は、Visual Studio Code を使用したカスタムアプリケーションのデバッグ方法を示しています。 ライブログの確認、ブレークポイントのヒット、コードのステップスルー、ローカルコード変更のライブ再読み込みをアクティベーションのたびにおこなうことができます。

aio では、これらの手順の多くが標準で自動化されます。 Adobe Developer App Builder ドキュメントのアプリケーションのデバッグの節を参照してください。 現時点では、以下の手順には回避策が含まれています。

コードの変更内容はすべてリアルタイムで読み込まれ、次回アクティベーションがおこなわれるとすぐに有効になります。