コンポーネントオブジェクトモデル（COM）は、テスト自動化プロジェクトにおけるテストの構造を整えるためのデザインパターンです。人気のあるページオブジェクトモデル（POM）に触発され、COMはページ全体を扱うことを超え、ボタン、テキストフィールド、ドロップダウンメニュー、その他の再利用可能な要素など、特定のUIコンポーネントに焦点を当てています。
このチュートリアルでは、Selenium WebDriverとCucumberを使用してWebアプリケーションをテストするためにCOMを実装する方法と、このアプローチによってテストがより柔軟でモジュール化され、メンテナンスが容易になる方法を説明します。
コンポーネントオブジェクトモデルとは何ですか？
コンポーネントオブジェクトモデル（COM）は、POMモデルの進化版です。全ページをオブジェクトとしてモデル化し、すべてのページ要素と相互作用するメソッドを持つのではなく、COMはユーザーインターフェースを個々のコンポーネントに分解します。例えば：
- ボタン
- テキストフィールド
- ドロップダウンメニュー
- 検索バー
- テーブル
各コンポーネントはJavaクラスにカプセル化され、その相互作用は特定のメソッドによって管理されるため、各要素は独立して維持およびテストできます。これにより、コードの再利用性、メンテナンス、テストの柔軟性が向上します。
なぜPOMの代わりにCOMを使用するのか？
1. モジュール性の向上
COMでは、各コンポーネント（ボタンやテキストフィールドなど）は独立したエンティティです。コンポーネントが変更された場合（例えば、ボタンのテキストが変更された場合）、他のコンポーネントやページに影響を与えずにコンポーネントクラスを修正するだけで済みます。これにより、高いモジュール性が実現され、わずかな調整のために全ページを修正する必要がなくなります。
2. 再利用性と柔軟性
コンポーネントはアプリケーションの複数のページで再利用できるため、コードの重複が減ります。例えば、ButtonComponentはボタンが表示される任意のページで使用でき、冗長性が減少し、テストの柔軟性が向上します。
3. メンテナンスの簡素化
COMを使用するとメンテナンスが容易になります。コンポーネントが変更された場合（例えば、ボタンやテキストフィールド）、そのコンポーネントを表すクラスを修正するだけで済みます。そのコンポーネントを使用するすべてのテストは、自動的に更新され、各テストシナリオを再訪する必要がありません。
4. 動的インターフェースへの適応
現代のアプリケーションはしばしば動的で、インターフェースが頻繁に変わります。COMはそのようなアプリケーションに最適で、インターフェースに依存せずにコンポーネントのテストを行うことができます。アプリケーションの他の部分のテストに影響を与えることなく、コンポーネントを修正または追加できます。
5. テスト自動化の高速化
COMはテスト自動化を加速します。コンポーネントとのインタラクションを再利用可能なクラスに集中させることで、テスターはすべてのページやコンポーネントに対してアクションを再定義する必要がありません。例えば、「ボタンをクリックする」単一ステップの定義は、プロジェクト内のすべてのテストで使用でき、テストの自動化に必要な時間を大幅に削減します。
6. テスター間の作業の繰り返しを避ける
COMを使用することで、テスターはすべてのテストで同じ作業を繰り返す必要がなくなります。「ボタンをクリックする」や「テキストを入力する」などの一般的なアクションに対する集中化されたステップ定義は、プロジェクト内のすべてのテスターが使用できます。これにより、テストの一貫性が確保され、不要な繰り返しを避けることができ、テスター間の効率とコラボレーションが向上します。
COMプロジェクトアーキテクチャ
COMベースのプロジェクトのアーキテクチャは、コンポーネント、ステップ定義、およびランナーの3つの主要要素を中心に構成されています。
1. コンポーネント
各コンポーネントは、ボタン、テキストフィールド、ドロップダウンメニューなどのUI要素を表します。これらのクラスは、要素とのすべての可能なインタラクションをカプセル化します。
ここにButtonComponentクラスの例があります：
public class ButtonComponent {
private WebDriver driver;
public ButtonComponent(WebDriver driver) {
this.driver = driver;
}
public void clickButton(String buttonText) {
WebElement button = driver.findElement(By.xpath("//button[text()='" + buttonText + "']"));
button.click();
}
}
2. ステップ定義
ステップ定義 は、Gherkinファイルで定義されたステップをコンポーネント内のメソッドにリンクします。彼らは、コンポーネントとインタラクションし、テストシナリオで指定されたアクションを実装する責任があります。
ここにButtonStepDefinitionの例があります：
public class ButtonStepDefinition {
private ButtonComponent buttonComponent;
public ButtonStepDefinition(WebDriver driver) {
this.buttonComponent = new ButtonComponent(driver);
}
@When("I click on the button {string}")
public void iClickOnTheButton(String buttonText) {
buttonComponent.clickButton(buttonText);
}
}
3. ランナー
ランナークラスは、JUnitまたはTestNGを使用してテストを実行する責任があります。これは、Cucumberを構成して、.featureファイルに定義されたテストシナリオを読み込み、ステップ定義を使用して実行します。
ここにTestRunnerの例があります：
@RunWith(Cucumber.class)
@CucumberOptions(
features = "src/test/resources/features",
glue = "com.componentObjectModel.stepDefinitions",
plugin = {"pretty", "html:target/cucumber-reports.html"}
)
public class TestRunner {
}
Gherkinシナリオの作成と説明
Cucumberを使用した自動化の重要な要素の1つは、テストシナリオを書くためにGherkin言語を使用することです。Gherkinは、非技術者にも読みやすく理解しやすい方法でテストを記述することを可能にします。
ここでは、以前に定義したButtonComponentを使用してボタンとのインタラクションをテストしたいシナリオを考えてみましょう。Gherkinでは次のように書かれるかもしれません：
Scenario: User clicks on the "Submit" button Given I am on the login page When I click on the button "Submit" Then I should be redirected to the homepage
シナリオの説明
シナリオ
このシナリオは、ユーザーがログインページで「送信」ボタンをクリックし、その後ホームページにリダイレクトされることを確認するアクションを説明しています。
- 私はログインページにいます: テストの初期状態は、ユーザーがログインページにいることです。
- 「送信」ボタンをクリックしたとき: テストで実行されるアクションは「送信」ボタンをクリックすることです。
- その後、ホームページにリダイレクトされるべきです: 期待される検証は、ユーザーがボタンをクリックした後にホームページにリダイレクトされることです。
COMとのリンク
このシナリオの各ステップは、ステップ定義にマッピングされており、ButtonStepDefinitionで、クリックアクションはButtonComponentによって処理されます。これにより、テストがモジュール化され、保守が容易になります。
追加の説明
手順が表示されたテキストをパラメータとして取ることに注意してください。これにより、シナリオがより読みやすく汎用的になります。たとえば、上記のシナリオでは、ボタン「送信」のテキストが直接ステップ「ボタンをクリックするとき」に使用されます。「送信」をクリックするとき」ステップ定義は他のボタンをテストするために再利用でき、単にGherkinシナリオのテキストを変更することで、「ステップ定義」が再利用されます。「ログイン」」。これにより、テストコードの再利用性が向上し、シナリオが直感的で柔軟になります。
COMを使用したステップの再利用性
COMの主な利点の1つは、異なるボタンに対するステップ定義の再利用性です。たとえば、「{string}」ボタンをクリックするという同じステップが、ボタンに表示されるテキストに関係なくすべてのボタンに使用できます。このCOMアプローチにより、ボタンのテキストに基づいてクリックアクションを動的にパラメータ化できます。
別のボタンを使用した別のシナリオを考えてみましょう:
シナリオ
User clicks on the "Login" button
Given I am on the login page
When I click on the button "Login"
Then, I should be redirected to the dashboard
両方のケースで、ButtonComponent内のclickButtonメソッドが使用されますが、シナリオに応じてボタンのテキストが変わります。これは、COMが同じコンポーネントとステップ定義を再利用することを可能にし、テストを柔軟かつモジュール化します。
COMがテスト自動化を向上させる方法
COMはテスト自動化をいくつかの方法で改善します：
- コードの重複削減：再利用可能なコンポーネントを使用することで、テストにおけるコードの重複を減らします。例えば、アプリケーションの複数のページで使用される
ButtonComponentは、繰り返しテストを書く必要をなくします。 - より読みやすく修正しやすいテスト：テストはページ固有の実装詳細から切り離されているため、より明確で理解しやすくなります。基盤となるページ構造を気にせずにコンポーネントとの対話に焦点を合わせることができます。
- メンテナンスの容易さ：コンポーネントへの変更（例：ボタンのテキスト変更）は、テストではなくコンポーネントクラスにのみ影響します。これにより、メンテナンスが非常にシンプルで迅速になります。
- より柔軟なテスト：コンポーネントが互いに独立しているため、テストは変化するUIに簡単に適応できます。新しいコンポーネントをテストしたり、既存のものを置き換えたりしても、他のテストに影響を与えることはありません。
COMデザインパターンはいつ推奨されますか？
このデザインパターンは、テストされるウェブアプリケーションがすべてのコンポーネントに対して統一されたデザインシステムを使用している場合に推奨されます。例えば、すべてのボタンが同じ方法で宣言されていて、すべてのUI要素に一貫した構造がある場合です。そのような場合、COMを使用することで、ボタンやテキストフィールドなどの各コンポーネントタイプとの対話を集中化でき、テストがよりモジュール化され、再利用可能で、メンテナンスが容易になります。
複数の製品でのステップ定義の再利用
同じデザインシステムを使用する複数の製品を開発およびテストしている場合、各コンポーネントのすべてのステップ定義とアクション（またはほぼすべて）を含むライブラリを作成できます。これにより、テスターはGherkinシナリオの作成に集中でき、テストは自動化されます。すべてのウェブ要素が同じ方法（HTML）で記述されているため、ボタン、テキストフィールド、その他のUI要素などのコンポーネントは、すべてのプロジェクトで一貫して動作します。
その結果、テスターはもはや同じタスクを繰り返す必要がありません — 複数のプロジェクトにわたる同一のコンポーネントに対してステップ定義とアクションを定義することです。このアプローチは時間を節約し、保守性を向上させます。ウェブ要素が変更された場合（たとえば、XPathが変更された場合）、その要素を共有ライブラリで更新するだけで済み、その変更はすべての自動化プロジェクトに自動的に適用されます。これにより、エラーのリスクが減少し、異なる製品間での更新がより効率的になります。
結論
コンポーネントオブジェクトモデル（COM）は、テスト自動化を整理するための強力なデザインパターンです。再利用可能なコンポーネントに焦点を当てることで、COMはよりモジュール化され、保守可能で、スケーラブルなテストを作成することを可能にします。このパターンは、ユーザーインターフェースが迅速に変化し、独立したコンポーネントとの相互作用が不可欠な現代のアプリケーションに特に有用です。
再利用可能なテスト、簡素化されたメンテナンス、柔軟なアーキテクチャを備えたCOMは、SeleniumとCucumberプロジェクトにおけるテスト自動化の理想的なソリューションです。
Source:
https://dzone.com/articles/com-design-pattern-selenium-and-cucumber