UI テスト

カスタム 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 テストを構築しています。

顧客オプトイン

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 テストの作成

Maven プロジェクトは、Docker ビルドコンテキストを生成します。 この Docker ビルドコンテキストでは、UI テストを含む Docker 画像を作成する方法を説明します。Cloud Manager ユーザーは、実際の UI テストを含む Docker 画像を生成するためにこの UI テストを含む Docker 画像を作成します。

この節では、UI テストプロジェクトをリポジトリに追加するために必要な手順について説明します。

Docker ビルドコンテキストの生成

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 分類子を割り当てます。さらに、アーカイブに含める必要があるファイルのリストが次のように表示されます。

• A Dockerfile（Docker イメージの作成に必須）
• この wait-for-grid.sh 以下に説明するスクリプト
• 実際の UI テスト。 test-module フォルダー

また、アセンブリ記述子は、UI テストのローカル実行中に生成される可能性のある一部のファイルを除外します。これにより、アーカイブのサイズが小さくなり、ビルドが高速になります。

Docker ビルドコンテキストを含むアーカイブは、Cloud Manager によって自動的に取得され、デプロイメントパイプライン中のテストを含む Docker イメージが作成されます。 最終的に、Cloud Manager は Docker イメージを実行して、アプリケーションに対する UI テストを実行します。

ビルドでは、0 または 1 つのアーカイブが生成されます。アーカイブがゼロの場合、テストステップはデフォルトで合格します。 ビルドで複数のアーカイブが生成される場合、どのアーカイブが選択されるかは非決定的です。

UI テストの書き込み

この節では、UI テストを含んだ Docker イメージが従う必要がある規則について説明します。Docker イメージは、前の節で説明した Docker ビルドコンテキストから作成されます。

環境変数

実行時に次の環境変数が Docker イメージに渡されます。

Selenium の準備が完了するのを待機中

テストを開始する前に、Selenium サーバーが実行状態にあることを Docker イメージ側で確認する必要があります。Selenium サービスの待機は、2 段階のプロセスです。

1. SELENIUM_BASE_URL 環境変数から Selenium サービスの URL を読み取ります。
2. Selenium API で公開されているステータスエンドポイントに対して定期的にポーリングを行います。

Selenium のステータスエンドポイントが肯定的な応答で応答すると、テストを開始できます。

テストレポートの生成

Docker イメージは、テストレポートを JUnit XML 形式で生成して、環境変数 REPORTS_PATH で指定されたパスに保存する必要があります。JUnit XML 形式は、テストの結果を報告するために広く使用されている形式です。 Docker イメージで Java と Maven を使用する場合、次のような標準のテストモジュールがあります。 Maven Surefire プラグイン および Maven Failsafe プラグイン では、すぐに使用できるレポートを生成できます。

Docker イメージが他のプログラミング言語やテストランナーで実装されている場合は、JUnit XML レポートの生成方法に関して、選択したツールのドキュメントを参照してください。

ファイルをアップロード

テストでは、テスト対象のアプリケーションにファイルをアップロードする必要が生じる場合があります。 テストに対する Selenium のデプロイメントを柔軟に保つために、Selenium に直接アセットをアップロードすることはできません。 ファイルをアップロードするには、代わりに次の手順を実行する必要があります。

1. UPLOAD_URL 環境変数で指定された URL にファイルをアップロードします。
   • アップロードは、マルチパートフォームを含んだ 1 つの POST リクエストで実行する必要があります。
   • このマルチパートフォームには、1 つのファイルフィールドが必要です。
   • これは curl -X POST ${UPLOAD_URL} -F "data=@file.txt" と同等です。
   • このような HTTP リクエストを実行する方法については、Docker イメージで使用されているプログラミング言語のドキュメントやライブラリを参照してください。
2. アップロードが成功した場合、リクエストは 200 OK タイプの text/plain 応答を返します。
   • この応答の内容は不透明なファイルハンドルです。
   • <input> 要素のファイルパスの代わりにこのハンドルを使用して、アプリケーション内のアップロードファイルをテストできます。