機能テスト

コードの品質と信頼性を確保するために、AEM as a Cloud Service デプロイメントプロセスに組み込まれている 3 種類の機能テストについて説明します。

概要

AEM as a Cloud Service には 3 種類の機能テストがあります。

すべての機能テストについて、デプロイメントプロセスの一環としてビルド概要画面の「ビルドログをダウンロード」ボタンを使用して、テストの詳細な結果を .zip ファイル形式でダウンロードできます。

これらのログには、実際の AEM ランタイムプロセスのログは含まれていません。これらのログへのアクセスについて詳しくは、ログへのアクセスと管理 を参照してください。

製品機能テストとサンプルのカスタム機能テストは、どちらも AEM テストクライアントに基づいています。

製品機能テスト

製品機能テストは、オーサリングタスクやレプリケーションタスクなど、AEM のコア機能の安定した HTTP 統合テスト(IT)のセットです。これらのテストは、アドビで管理され、コア機能に障害が発生した場合に、カスタムアプリケーションコードに対する変更がデプロイされるのを防ぐことを目的としています。

製品機能テストは、新しいコードを Cloud Manager にデプロイするたびに自動的に実行され、省略することはできません。

製品機能テストは、オープンソースプロジェクトとして維持管理されます。詳しくは、GitHub の製品機能テストを参照してください。

カスタム機能テスト

製品機能テストはアドビで定義されますが、独自のアプリケーション用に独自の品質テストを作成することもできます。これは、アプリケーションの品質を確保するために、カスタム機能テストとして実稼動パイプラインの一環として実行されます。

カスタム機能テストは、カスタムコードデプロイメントとプッシュアップグレードの両方について実行されます。そのため、AEM コードの変更によってアプリケーションコードが機能しなくなることを防ぐ適切な機能テストを作成することが特に重要になります。カスタム機能テストステップは常に存在し、スキップできません。

カスタム機能テストの作成

アドビが製品機能テストの作成に使用するのと同じツールを、カスタム機能テストの作成に使用できます。テストの作成方法の例として、GitHub の製品機能テストを参照してください。

カスタム機能テストのコードは、プロジェクトの it.tests フォルダーにある Java コードです。すべての機能テストを含んだ 1 つの JAR が生成されます。ビルドで複数のテスト JAR が生成される場合、どの JAR が選択されるかは非決定的です。テスト JAR がゼロになる場合、テスト手順はデフォルトで合格します。テストのサンプルについては、AEM プロジェクトのアーキタイプを参照してください。

テストは、少なくとも 2 つのオーサーインスタンス、2 つのパブリッシュインスタンス、Dispatcher 設定など、アドビが維持管理するテストインフラストラクチャで実行されます。つまり、カスタム機能テストは AEM スタック全体に対して実行されます。

カスタム機能テストは、AEM にデプロイするアーティファクトと同じ Maven ビルドで生成される個別の JAR ファイルとしてパッケージ化する必要があります。一般に、これは別個の Maven モジュールになります。結果として生成される JAR ファイルには、必要な依存関係がすべて含まれている必要があり、通常は jar-with-dependencies 記述子を使用する maven-assembly-plugin で作成されます。

さらに、この JAR では、Cloud-Manager-TestType マニフェストヘッダーが integration-test に設定されている必要があります。

以下は maven-assembly-plugin の設定例です。

<build>
    <plugins>
        <!-- Create self-contained jar with dependencies -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-assembly-plugin</artifactId>
            <version>3.1.0</version>
            <configuration>
                <descriptorRefs>
                    <descriptorRef>jar-with-dependencies</descriptorRef>
                </descriptorRefs>
                <archive>
                    <manifestEntries>
                        <Cloud-Manager-TestType>integration-test</Cloud-Manager-TestType>
                    </manifestEntries>
                </archive>
            </configuration>
            <executions>
                <execution>
                    <id>make-assembly</id>
                    <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>
    </plugins>

この JAR ファイル内で、実行する実際のテストのクラス名は IT で終わる必要があります。

例えば、com.myco.tests.aem.it.ExampleIT という名前のクラスは実行されますが、com.myco.tests.aem.it.ExampleTest という名前のクラスは実行されません。

さらに、コードスキャンのカバレッジチェックからテストコードを除外するには、テストコードを it という名前のパッケージの下に置く必要があります(カバレッジ除外フィルターは **/it/**/*.java です)。

テストクラスは、通常の JUnit テストにする必要があります。テストインフラストラクチャは、aem-testing-clients テストライブラリで使用される規則との互換性を持つように設計および設定されています。開発者は、このライブラリを使用し、そのライブラリのベストプラクティスに従うことを強くお勧めします。

詳しくは、aem-testing-clients GitHub リポジトリーを参照してください。

ヒント

カスタム機能テストを使用して CI/CD パイプラインの信頼性を向上させる方法については、このビデオをご覧ください。

カスタム UI テスト

カスタム UI テストは、アプリケーションの UI テストを作成して自動的に実行できるオプション機能です。UI テストは、言語とフレームワークの幅広い選択肢(Java と Maven、Node と WebDriver.io、Selenium に基づいて構築されたその他のフレームワークとテクノロジーなど)を可能にするために Docker イメージにパッケージ化された Selenium ベースのテストです。

詳しくは、カスタム UI テストを参照してください。

ローカルテストの実行

テストクラスは JUnit テストなので、Eclipse、IntelliJ、NetBeans などの主要な Java IDE から実行できます。製品機能テストとカスタム機能テストはどちらも同じテクノロジーに基づいているので、製品テストをカスタムテストにコピーすることで、両者をローカルで実行できます。

ただし、これらのテストを実行する際は、aem-testing-clients(およびそのベースとなる Sling Testing Client)ライブラリで想定されている様々なシステムプロパティを設定する必要があります。

これらのシステムプロパティは次のとおりです。

  • sling.it.instances - should be set to 2
  • sling.it.instance.url.1 - should be set to the author URL, for example, http://localhost:4502
  • sling.it.instance.runmode.1 - should be set to author
  • sling.it.instance.adminUser.1 - should be set to the author admin user, e.g. admin
  • sling.it.instance.adminPassword.1 - should be set to the author admin password
  • sling.it.instance.url.2 - should be set to the publish URL, for example, http://localhost:4503
  • sling.it.instance.runmode.2 - should be set to publish
  • sling.it.instance.adminUser.2 - should be set to the publish admin user, for example, admin
  • sling.it.instance.adminPassword.2 - should be set to the publish admin password

このページ