カスタム UI テストは、アプリケーションの UI テストを作成して自動的に実行できるオプションの機能です。
AEMは、 Cloud Manager の品質ゲート カスタムアプリケーションのスムーズな更新を確保する。 特に、AEM API を使用したカスタムテストの作成と自動化を IT テストゲートで実行しています。
UI テストは、言語とフレームワークの幅広い選択肢(Java と Maven、Node と WebDriver.io、Selenium に基づいて構築されたその他のフレームワークとテクノロジーなど)を可能にするために Docker イメージにパッケージ化された Selenium ベースのテストです。さらに、 AEMプロジェクトアーキタイプ
UI テストは、Cloud Manager の各パイプラインの特定の品質ゲートの一部として、 専用 カスタム UI テスト 手順 回帰や新しい機能を含む UI テストでは、エラーの検出とレポートが可能です。
Java で記述された HTTP テストであるカスタム機能テストとは異なり、UI テストは、の節で定義された規則に従う限り、任意の言語で記述されたテストを含む Docker イメージにすることができます UI テストを構築しています。
Adobeでは、 AEMプロジェクトアーキタイプ。
Cloud Manager で UI テストを作成して実行するには、リポジトリにファイルを追加して、この機能をオプトインする必要があります。
ファイル名は testing.properties
にする必要があります。
ファイルの内容は、 ui-tests.version=1
.
ファイルは、UI テスト用の Maven サブモジュールの下で、 pom.xml
UI テストサブモジュールのファイル。
ファイルは、ビルドのルートにある必要があります 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 テストが導入される前にプロジェクトに導入され、クライアントがファイルを編集する意図がなかったためです。 これは無視しても問題ありません。
Maven プロジェクトは、Docker ビルドコンテキストを生成します。 この Docker ビルドコンテキストでは、UI テストを含む Docker 画像を作成する方法を説明します。Cloud Manager ユーザーは、実際の UI テストを含む Docker 画像を生成するためにこの UI テストを含む Docker 画像を作成します。
この節では、UI テストプロジェクトをリポジトリに追加するために必要な手順について説明します。
この AEM Project Archetype では、プログラミング言語に関する特別な要件を持たない UI テストプロジェクトを生成できます。
Docker ビルドコンテキストを生成するには、次の処理を行う Maven モジュールが必要です。
Dockerfile
と、テストを含んだ Docker イメージの作成に必要なその他のすべてのファイルを格納したアーカイブを作成する。ui-test-docker-context
分類子をタグ付けする。これをおこなう最も簡単な方法は、 Maven Assembly Plugin 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>
この実行は、Maven Assembly Plugin に対し、 assembly-ui-test-docker-context.xml
と呼ばれる アセンブリ記述子 プラグインの用語。 アセンブリ記述子では、アーカイブに含める必要のあるすべてのファイルがリストアップされます。
<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
フォルダーまた、アセンブリ記述子は、UI テストのローカル実行中に生成される可能性のある一部のファイルを除外します。これにより、アーカイブのサイズが小さくなり、ビルドが高速になります。
Docker ビルドコンテキストを含むアーカイブは、Cloud Manager によって自動的に取得され、デプロイメントパイプライン中のテストを含む Docker イメージが作成されます。 最終的に、Cloud Manager は Docker イメージを実行して、アプリケーションに対する UI テストを実行します。
ビルドでは、0 または 1 つのアーカイブが生成されます。アーカイブがゼロの場合、テストステップはデフォルトで合格します。 ビルドで複数のアーカイブが生成される場合、どのアーカイブが選択されるかは非決定的です。
この節では、UI テストを含んだ Docker イメージが従う必要がある規則について説明します。Docker イメージは、前の節で説明した Docker ビルドコンテキストから作成されます。
実行時に次の環境変数が Docker イメージに渡されます。
変数 | 例 | 説明 |
---|---|---|
SELENIUM_BASE_URL |
http://my-ip:4444 |
Selenium サーバーの URL |
SELENIUM_BROWSER |
chrome |
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 |
Selenium からファイルにアクセスできるようにするためのファイルアップロード先の URL |
テストを開始する前に、Selenium サーバーが実行状態にあることを Docker イメージ側で確認する必要があります。Selenium サービスの待機は、2 段階のプロセスです。
SELENIUM_BASE_URL
環境変数から Selenium サービスの URL を読み取ります。Selenium のステータスエンドポイントが肯定的な応答で応答すると、テストを開始できます。
Docker イメージは、テストレポートを JUnit XML 形式で生成して、環境変数 REPORTS_PATH
で指定されたパスに保存する必要があります。JUnit XML 形式は、テストの結果を報告するために広く使用されている形式です。 Docker イメージで Java と Maven を使用する場合、次のような標準のテストモジュールがあります。 Maven Surefire プラグイン および Maven Failsafe プラグイン では、すぐに使用できるレポートを生成できます。
Docker イメージが他のプログラミング言語やテストランナーで実装されている場合は、JUnit XML レポートの生成方法に関して、選択したツールのドキュメントを参照してください。
テストでは、テスト対象のアプリケーションにファイルをアップロードする必要が生じる場合があります。 テストに対する Selenium のデプロイメントを柔軟に保つために、Selenium に直接アセットをアップロードすることはできません。 ファイルをアップロードするには、代わりに次の手順を実行する必要があります。
UPLOAD_URL
環境変数で指定された URL にファイルをアップロードします。
curl -X POST ${UPLOAD_URL} -F "data=@file.txt"
と同等です。200 OK
タイプの text/plain
応答を返します。
<input>
要素のファイルパスの代わりにこのハンドルを使用して、アプリケーション内のアップロードファイルをテストできます。