カスタム UI テストは、アプリケーションの UI テストを作成して自動的に実行できるオプション機能です。
AEM には、Cloud Manager 品質ゲートの統合スイートが用意されており、カスタムアプリケーションをスムーズに更新できるようになっています。特に、IT テストゲートでは、AEM API を使用したカスタムテストの作成と自動化に既に対応しています。
UI テストは、言語およびフレームワーク(Cypress、Selenium、Java および Maven、JavaScript など)の幅広い選択を可能にするために、Docker イメージでパッケージ化されています。 また、AEM プロジェクトアーキタイプを使用すると、UI テストプロジェクトを容易に生成できます。
Adobeは、リアルタイムの再読み込みと自動待ちを提供するので、Cypress を使用することを推奨します。これにより、時間を節約し、テスト中の生産性を向上させることができます。 Cypress は、簡単で直感的な構文を提供し、テストを初めて行うユーザーでも簡単に学習し、使用できます。
UI テストは、実稼動パイプラインまたはオプションで非実稼動パイプラインのカスタム UI テスト手順で、各 Cloud Manager パイプラインの特定の品質ゲートの一部として実行します。回帰や新しい機能を含む UI テストでは、エラーの検出とレポートが可能です。
UI テストは、Java で記述された HTTP テストであるカスタム機能テストとは異なり、UI テストの作成の節で定義されている規則に従う限り、任意の言語で記述されたテストを含む Docker イメージにすることができます。
Adobeでは、UI テストに Cypress を使用することをお勧めします ( AEM Test Samples リポジトリ.
Adobeでは、WebdriverIO を使用した JavaScript に基づく UI テストモジュールの例も提供しています ( AEM Project Archetype) および Java と WebDriver( AEM Test Samples リポジトリ) をクリックします。
この節では、Cloud Manager で実行用の UI テストの設定に必要な手順について説明します。
使用するプログラミング言語を決定します。
Cypress の場合は、 AEM Test Samples リポジトリ.
JavaScript と WDIO の場合は、Cloud Manager リポジトリの ui.tests
フォルダーに自動的に生成されるサンプルコードを使用します。
Cloud Manager が ui.tests
フォルダーを自動作成する前にリポジトリが作成された場合は、AEM プロジェクトアーキタイプを使用して最新バージョンを生成することもできます。
Java および WebDriver の場合は、AEM テストサンプルのリポジトリからサンプルコードを使用します。
その他のプログラミング言語については、 UI テストの構築 このドキュメントでは、テストプロジェクトを設定します。
このドキュメントの顧客オプトインの節に従って、UI テストがアクティベートされていることを確認してください。
テストケースを作成し、 ローカルでテストを実行する.
コードを Cloud Manager リポジトリにコミットし、Cloud Manager パイプラインを実行します。
Maven プロジェクトでは、Docker ビルドコンテキストを生成します。この Docker ビルドコンテキストでは、UI テストを含む Docker イメージを作成する方法を説明します。Cloud Manager はこれを使用して、実際の UI テストを含む Docker イメージを生成します。
この節では、UI テストプロジェクトをリポジトリーに追加するために必要な手順について説明します。
この AEM Project Archetype では、次の説明に準拠した UI テストプロジェクトを生成できます。プログラミング言語に関する特別な要件がない場合は、このプロジェクトが適用されます。
Docker ビルドコンテキストを生成するには、次の Maven モジュールが必要です。
Dockerfile
と、テストを含んだ Docker イメージの作成に必要なその他のすべてのファイルを格納したアーカイブを作成する。ui-test-docker-context
分類子をタグ付けする。これを行うには、Maven アセンブリプラグインを設定して Docker ビルドコンテキストアーカイブを作成し、それに適切な分類子を割り当てるのが最も簡単です。
様々なテクノロジーとフレームワークを使用して UI テストを作成できますが、この節では、プロジェクトが次のようにレイアウトされていることを前提としています。
├── Dockerfile
├── assembly-ui-test-docker-context.xml
├── pom.xml
├── test-module
│ ├── package.json
│ ├── index.js
│ └── wdio.conf.js
└── wait-for-grid.sh
pom.xml
ファイルは Maven ビルドを扱います。次のような Maven アセンブリプラグインに実行を追加します。
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptors>
<descriptor>${project.basedir}/assembly-ui-test-docker-context.xml</descriptor>
</descriptors>
<tarLongFileMode>gnu</tarLongFileMode>
</configuration>
<executions>
<execution>
<id>make-assembly</id>
<phase>package</phase>
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
この実行は、assembly-ui-test-docker-context.xml
に含まれている命令(プラグインの専門用語ではアセンブリ記述子と呼ばれます)に基づいてアーカイブを作成するように Maven アセンブリプラグインに指示します。アセンブリ記述子では、アーカイブに含める必要のあるすべてのファイルがリストアップされます。
<assembly>
<id>ui-test-docker-context</id>
<includeBaseDirectory>false</includeBaseDirectory>
<formats>
<format>tar.gz</format>
</formats>
<fileSets>
<fileSet>
<directory>${basedir}</directory>
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
</includes>
</fileSet>
<fileSet>
<directory>${basedir}/test-module</directory>
<excludes>
<exclude>node/**</exclude>
<exclude>node_modules/**</exclude>
<exclude>reports/**</exclude>
</excludes>
</fileSet>
</fileSets>
</assembly>
アセンブリ記述子は、.tar.gz
タイプのアーカイブを作成するようにプラグインに指示し、そのアーカイブに ui-test-docker-context
分類子を割り当てます。さらに、そのアーカイブに含める必要のある次のファイルがリストアップされます。
Dockerfile
:Docker イメージの作成に必須wait-for-grid.sh
スクリプト:目的は後述のとおりtest-module
フォルダー内に Node.js プロジェクトで実装また、アセンブリ記述子は、UI テストのローカル実行中に生成される可能性のある一部のファイルを除外します。これにより、アーカイブのサイズが小さくなり、ビルドが高速になります。
Docker ビルドコンテキストを含んだアーカイブが Cloud Manager で自動的に選択され、テストを含んだ Docker イメージがデプロイメントパイプライン中に作成されます。最終的に、Cloud Manager は Docker イメージを実行して、アプリケーションに対する UI テストを実行します。
ビルドでは、0 または 1 つのアーカイブが生成されます。アーカイブが 0 の場合、テストステップはデフォルトで通過します。ビルドで複数のアーカイブが生成される場合、どのアーカイブが選択されるかは非決定的です。
Cloud Manager で UI テストを作成して実行するには、リポジトリにファイルを追加して、この機能をオプトインする必要があります。
testing.properties
にする必要があります。ui-tests.version=1
にする必要があります。pom.xml
ファイルの横にある UI テスト用 Maven サブモジュールの下にある必要があります。tar.gz
ファイルのルートに必要です。このファイルが存在しない場合、UI テストの作成と実行はスキップされます。
testing.properties
ファイルをビルドアーティファクトに含めるには、include
ステートメントを assembly-ui-test-docker-context.xml
ファイルを追加します。
[...]
<includes>
<include>Dockerfile</include>
<include>wait-for-grid.sh</include>
<include>testing.properties</include> <!-- opt-in test module in Cloud Manager -->
</includes>
[...]
プロジェクトにこの行が含まれていない場合、UI テストをオプトインするには、このファイルを編集する必要があります。
このファイルには、編集しないように指示する行が含まれている場合があります。これは、オプトイン UI テストが導入される前にプロジェクトに導入され、クライアントがファイルを編集する意図がなかったためです。 これは無視してかまいません。
アドビが指定したサンプルを使用する場合:
AEM プロジェクトアーキタイプに基づいて生成された JavaScript ベースの ui.tests
フォルダーの場合、以下のコマンドを実行して必要な設定を追加できます。
echo "ui-tests.version=1" > testing.properties
if ! grep -q "testing.properties" "assembly-ui-test-docker-context.xml"; then
awk -v line=' <include>testing.properties</include>' '/<include>wait-for-grid.sh<\/include>/ { printf "%s\n%s\n", $0, line; next }; 1' assembly-ui-test-docker-context.xml > assembly-ui-test-docker-context.xml.new && mv assembly-ui-test-docker-context.xml.new assembly-ui-test-docker-context.xml
fi
Adobeが提供する Cypress および Java Selenium のテストサンプルには、既にオプトインフラグが設定されています。
この節では、UI テストを含んだ Docker イメージが従う必要がある規則について説明します。Docker イメージは、前の節で説明した Docker ビルドコンテキストから作成されます。
フレームワークに応じて、実行時に次の環境変数が Docker イメージに渡されます。
変数 | 例 | 説明 | テストフレームワーク |
---|---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
Selenium サーバーの URL | Selenium のみ |
SELENIUM_BROWSER |
chrome |
Selenium サーバーで使用されるブラウザー実装 | Selenium のみ |
AEM_AUTHOR_URL |
http://my-ip:4502/context-path |
AEM オーサーインスタンスの URL | すべて |
AEM_AUTHOR_USERNAME |
admin |
AEM オーサーインスタンスにログインするためのユーザー名 | すべて |
AEM_AUTHOR_PASSWORD |
admin |
AEM オーサーインスタンスにログインするためのパスワード | すべて |
AEM_PUBLISH_URL |
http://my-ip:4503/context-path |
AEM パブリッシュインスタンスの URL | すべて |
AEM_PUBLISH_USERNAME |
admin |
AEM パブリッシュインスタンスにログインするためのユーザー名 | すべて |
AEM_PUBLISH_PASSWORD |
admin |
AEM パブリッシュインスタンスにログインするためのパスワード | すべて |
REPORTS_PATH |
/usr/src/app/reports |
テスト結果の XML レポートの保存先となるパス | すべて |
UPLOAD_URL |
http://upload-host:9090/upload |
テストフレームワークにアクセスできるようにファイルをアップロードする必要がある URL | すべて |
アドビテストサンプルには、設定パラメーターにアクセスするためのヘルパー関数が用意されています。
Cypress.env('VARIABLE_NAME')
Docker イメージは、テストレポートを JUnit XML 形式で生成して、環境変数 REPORTS_PATH
で指定されたパスに保存する必要があります。JUnit XML 形式は、テストの結果を報告するために広く使用されている形式です。 Docker イメージで Java と Maven を使用する場合、Maven Surefire プラグインや Maven Failsafe プラグイン などの標準テストモジュールでは、すぐに使用できるレポートを生成できます。
Docker イメージが他のプログラミング言語またはテストランナーで実装されている場合は、選択したツールのドキュメントを参照して、JUnit XML レポートの生成方法を確認してください。
UI テスト手順の結果は、テストレポートに基づいてのみ評価されます。 テストの実行に合わせてレポートを生成していることを確認します。
エラーを STDERR に記録したり、ゼロ以外の終了コードを返すのではなく、アサーションを使用してください。そうしない場合、デプロイメントパイプラインが正常に実行されます。
ローカルマシンから機能テストを実行する場合は、管理者のような権限を持つユーザーを作成して、同じ動作を実現します。
タイプ | 値 | 説明 |
---|---|---|
CPU | 2.0 | テスト実行ごとに確保される CPU 時間の量です。 |
メモリ | 1Gi | テストに割り当てられたメモリ量(GB 単位) |
タイムアウト | 30m | テストが終了するまでの期間。 |
推奨期間 | 15m | Adobeは、この時間を超えないようにテストを書き込むことをお勧めします。 |
さらにリソースが必要な場合は、カスタマーケアケースを作成し、使用例を説明します。Adobeがリクエストを確認し、適切な支援を提供します。
この節は、選択されたテストインフラストラクチャが Selenium の場合にのみ適用されます。
テストを開始する前に、Selenium サーバーが実行状態にあることを Docker イメージ側で確認する必要があります。Selenium サービスの準備が完了するまで、次の 2 段階の手順で待機します。
SELENIUM_BASE_URL
環境変数から Selenium サービスの URL を読み取ります。Selenium のステータスエンドポイントが肯定的な応答を返したら、テストを開始できます。
Adobe UI のテストサンプルでは、これをスクリプト wait-for-grid.sh
で処理します。Docker の起動時に実行され、グリッドの準備が整った場合にのみ、実際のテストが実行されます。
Docker イメージでは、追加のテスト出力(スクリーンショットやビデオなど)が生成され、環境変数で指定されたパスに保存される場合があります REPORTS_PATH
. REPORTS_PATH
の下にあるファイルはすべて、テスト結果のアーカイブに含まれます。
デフォルトでアドビが提供するテストサンプルは、失敗したテストのスクリーンショットを作成します。
ヘルパー関数を使用して、テストのスクリーンショットを作成できます。
UI テストの実行中にテスト結果アーカイブが作成された場合は、カスタム UI テスト手順の下にある「Download Details
」ボタンを使用して、Cloud Manager からダウンロードできます。
テストでは、場合によって、テスト中のアプリケーションにファイルをアップロードする必要があります。テストに対する Selenium のデプロイメントを柔軟に保つため、Selenium に直接アセットをアップロードすることはできません。 ファイルをアップロードするには、代わりに次の手順を実行する必要があります。
UPLOAD_URL
環境変数で指定された URL にファイルをアップロードします。
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
と同等です。200 OK
タイプの text/plain
応答を返します。
<input>
要素のファイルパスの代わりにこのハンドルを使用して、アプリケーション内のアップロードファイルをテストできます。Cloud Manager パイプラインで UI テストをアクティブ化する前に、UI テストを
AEM as a Cloud Service SDK に対してローカルで実行するか、
実際の AEM as a Cloud Service インスタンスに対してローカルで実行することをお勧めします。
シェルを開き、リポジトリ内の ui.tests/test-module
フォルダーに移動します
Cypress とその他の前提条件のインストール
npm install
テストの実行に必要な環境変数の設定
export AEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com
export AEM_AUTHOR_USERNAME=<user>
export AEM_AUTHOR_PASSWORD=<password>
export AEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com
export AEM_PUBLISH_USERNAME=<user>
export AEM_PUBLISH_PASSWORD=<password>
export REPORTS_PATH=target/
次のいずれかのコマンドでテストを実行します。
npm test # Using default Cypress browser
npm run test-chrome # Using Google Chrome browser
npm run test-firefox # Using Firefox browser
ログファイルは、 target/
リポジトリのフォルダー。
詳しくは、 AEM Test Samples リポジトリ.
シェルを開き、リポジトリ内の ui.tests
フォルダーに移動します
Maven を使用してテストを開始するには、次のコマンドを実行します
mvn verify -Pui-tests-local-execution \
-DAEM_AUTHOR_URL=https://author-<program-id>-<environment-id>.adobeaemcloud.com \
-DAEM_AUTHOR_USERNAME=<user> \
-DAEM_AUTHOR_PASSWORD=<password> \
-DAEM_PUBLISH_URL=https://publish-<program-id>-<environment-id>.adobeaemcloud.com \
-DAEM_PUBLISH_USERNAME=<user> \
-DAEM_PUBLISH_PASSWORD=<password>
target/reports
フォルダーに保存されます。詳しくは、 AEM Project Archetype リポジトリ.
シェルを開き、リポジトリ内の ui.tests/test-module
フォルダーに移動します
Maven を使用してテストを開始するには、次のコマンドを実行します
# Start selenium docker image (for x64 CPUs)
docker run --platform linux/amd64 -d -p 4444:4444 selenium/standalone-chrome-debug:latest
# Start selenium docker image (for ARM CPUs)
docker run -d -p 4444:4444 seleniarm/standalone-chromium
# Run the tests using the previously started Selenium instance
mvn verify -Pui-tests-local-execution -DSELENIUM_BASE_URL=http://<server>:4444
ログファイルは、 target/reports
リポジトリのフォルダー。
詳しくは、 AEM Test Samples リポジトリ.