はじめに
AEM as a Cloud Service デプロイメントプロセスで使用できる品質ゲートおよび様々なタイプの組み込み機能テストについて説明します。包括的なテスト戦略のフレームワーク内で、どのように使用して、最適化できるかについて説明します。
機能テストについて
次の図は、テスト戦略全体のコンテキストで使用可能なパイプラインの概要と、AEM as a Cloud Service デプロイメントプロセスを示しています。
機能テストの目的
AEM Cloud Service デプロイメントパイプラインの目的は、開発および AEM 製品リリースのライフサイクルの様々な段階で、堅牢で安全なデプロイメントを容易にすることです。これらのパイプラインには、様々なレベルで複数の品質ゲートが組み込まれており、AEM アプリケーションの変更と AEM 製品のアップデートの両方に対するデプロイメントの整合性と安全性を確保できます。
Adobeには、いくつかの組み込みの品質ゲートが用意されていますが、実装と設定に対してユーザーが介入する必要がある場合もあります。これらの品質ゲートは汎用性が高く、様々なライフサイクル段階で適用され、開発設定や CI/CD プロセスに直接統合されます。
組み込みの品質ゲートでは、AEMアプリケーションのコンテキスト内でAEM製品の機能を主に検証します。一方、設定したカスタム品質ゲートは、アプリケーションの重要な機能とユーザーインタラクションが意図したとおりに実行されることを検証するように設計されています。これら 2 つの品質ゲートをまとめて連携させ、コードの変更と AEM 製品のアップデートの両方に対する堅牢で安全な自動デプロイメントを実現します。
これらの品質ゲートは、テスト戦略全体の包括的なテストフレームワークではないことに注意する必要があります。AEM 製品は、AEM Cloud Service のデプロイメントプロセスに入る前に、広範なテストが行われます。同様に、アプリケーションは、デプロイメントフェーズに達する前に、既に高品質である必要があります。このアプローチは、品質ゲートが完全なテスト計画の代わりとなるのではなく、デプロイメントプロセスを保護する主要目的に焦点を当てるようにします。
テストの品質ゲート
次の図は、使用可能な品質ゲートの詳細図、テスト戦略全体でのその使用状況、および AEM as a Cloud Service デプロイメントプロセスを示します。
顧客が提供する品質ゲートの概要
| 単体テスト | カスタム 機能テスト | カスタム UI テスト | 顧客 検証 | 手動 テスト | |
|---|---|---|---|---|---|
| 実稼動パイプライン | あり ブロック | あり ブロック 60m タイムアウト | あり ブロック 30m タイムアウト | 不可 | 不可 |
| 実稼動以外のパイプライン | あり ブロック | オプトイン ブロック 60m タイムアウト | オプトイン ブロック 30m タイムアウト | 不可 | 不可 |
| Adobe 内部検証 | あり ブロック | あり ブロック 60m タイムアウト | あり ブロック 30m タイムアウト | 不可 | 不可 |
| 顧客の CI/CD | はい | はい | はい | はい | はい |
| 顧客のローカル開発者 | はい | はい | はい | はい | はい |
単体テスト
すべてのテスト戦略の基盤となる、AEM アプリケーションの単体テストを実施することをお勧めします。このテストは、高速かつ頻繁な実行と早期の迅速なフィードバックの提供を目的としており、開発者ワークフロー、独自の CI/CD、AEM Cloud Service デプロイメントパイプラインに緊密に統合されています。
また、JUnit を使用して実装され、Maven で実行されます。AEM の単体テストの例と導入方法については、AEM プロジェクトアーキタイプのコアモジュールを参照してください。
コード品質
この品質ゲートは標準で設定され、AEM アプリケーションコードで静的コード分析を実行します。
詳しくは、コード品質テストおよびカスタムコード品質ルールを参照してください。
製品テスト
製品機能テストは、オーサリングタスクやレプリケーションタスクなど、AEM のコア機能に対する安定した HTTP 統合テスト（IT）です。アドビでは、これらを標準で提供、保守しています。これは、カスタムアプリケーションコードが AEM 製品のコア機能を破壊した場合に、カスタムアプリケーションコードに対する変更がデプロイされるのを防ぐためのものです。
実装には JUnit を使用し、Maven で実行され、公式の AEM テストクライアントに依存します。製品テストスイートは
オープンソースプロジェクトとして管理され、ベストプラクティスを採用しているので、テスト実装の出発点として適しています。
カスタム機能テスト
製品テストと同様に、顧客の機能テストは HTTP 統合テスト（IT）です。これは、JUnit を使用して実装、Maven を使用して実行、および公式の AEM テストクライアント上に構築されます。
メモ効率的なパイプラインの実行を維持するために、アドビは機能テストのランタイムを約 15 分以下にすることを目標にして、主な機能と主要なユーザーインタラクションフローに重点を置くことを推奨しています。今回を上回る完全な機能テストスイートは、開発プロセス中に一般的な顧客検証パイプラインの一部として実行する必要があります。
例については、オープンソースの製品テストまたは AEM プロジェクトアーキタイプの it.tests モジュールを参照してください。
詳しくは、Java 機能テストを参照してください。
カスタム UI テスト
顧客固有の開発に対するリスク管理を最大限に高めるために、アドビでは重要な UI テストを AEM as a Cloud Service に取り込むことをお勧めします。それらを限定的に保持し、顧客体験への影響を最大化することに重点を置きます。
テストは、可能な限り揮発性に設計された Docker イメージにパッケージ化されます（Cypress、Playwright、Selenium、Java およびJavaScriptをサポート）。 カスタム機能テストと同様に、同じ特性と目的に従います。
メモパイプラインの実行を効率化するために、アドビでは主な機能とユーザーのインタラクションフローに注力することをお勧めします。この品質ゲートを上回る完全な UI テストスイートは、一般的な顧客検証パイプラインの一部として実行する必要があります。それらを顧客の開発プロセスに組み込みます。
例として、オープンソースのサンプルテストまたは AEMプロジェクトアーキタイプの ui.tests モジュールを参照してください。
詳しくは、カスタム UI テストを参照してください。