ページオブジェクトモデル+ Webdriver。 1つのテスト実装例

この記事を書くことにしました このアプローチは、テスト自動化プロジェクトの構造を整理するのに最も効果的だと思います。

残念ながら、WebdriverまたはSelenium以外の自動化ツールは使用しませんでした。 しかし、それにもかかわらず、このアプローチは他のツールで使用できるように思えます。

コード例はC＃+ NUnitになります。

この記事は私自身の経験を反映したものであり、リンクや引用は含まれていません。 以下の文章は、このアプローチに対する私のビジョンの物語に過ぎず、決して仮説として提示されるものではありません。

なぜそんなに効果的ですか？

おそらく彼がこのかけがえのない秩序をプロジェクトの構造に取り入れたからでしょう。 このアプローチの原則に従って、論理モジュールを明確に記述した構造を作成します。 そして、そのような各モジュールは、テスト対象のアプリケーションの論理モジュールを反映しています。

これにより、メソッドの検索と再利用が大幅に促進され、その結果、プロジェクトのメンテナンスが容易になります。 また、新しい参加者がプロジェクトに「注ぐ」ために必要な時間を大幅に削減します。

構造

例は、1つの簡単なテスト-Facebookログイン（ページの右上隅に表示されるログインを考慮します）です。



このプロジェクトの実装例は、 github.com/DmitryRoss/Page-Object-Model-Articleからダウンロードできます。



-プロジェクト全体の先頭には、NUnitテストを含むクラスがあります。 テストでは、このようなクラスを1つ作成し、LoginTestsと呼びます。 その中で、AssertLogin（）というテストメソッドを作成します。

[TestFixture] public class LoginTests : BaseTests { static LoginHelper loginHelper = new LoginHelper(); [Test] public static void AssertLogin(){...} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-以下はヘルパークラスです。 そのような各クラスは、テストで特定の1つのクラスを提供します。

しかし、時には、ヘルパークラスの一部のメソッドが、テストや他のヘルパークラスを備えた他のクラスで必要になることがあります。 この場合、そのようなメソッドを、構造の階層内でヘルパークラスと同じレベルにある個別の一般クラスに転送することをお勧めします。 このクラスの顕著な例は、アプリケーションナビゲーションクラスです。 結局のところ、特定のページへの移行は、テストまたはヘルパークラスを持つさまざまなクラスで必要になる場合があります。 通常、すべてのプロジェクトには、共通としてレンダリングされる他のヘルパークラスがあります。

便宜上、メソッドは、それらが存在するヘルパークラスのインスタンスを返します。 これにより、ドットを介して、そのような省略形でそれらにアクセスできます-

  loginHelper. DoLogin(userName, password). AssertUserName(displayedUserName);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、このようなクラスを1つ作成し、LoginHelperと呼びます。

その中で、2つのメソッドを作成します。

1. DoLogin（文字列userName、文字列パスワード）

2. AssertUserName（文字列userName）

 public class LoginHelper :TestFramework { public LoginHelper DoLogin(string userName, string password){...} public LoginHelper AssertUserName(string userName){...} }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

-そして、ここから私たちのプロジェクトの中核が始まります-Pages、つまり ページ。 これらは、アプリケーションのページを持つクラスです。 つまり そのような各クラスは、アプリケーションの特定のページに対応し、このページのロケーターとWeb要素を含みます。 さらに、彼はこのページでヘルパークラスによって使用される基本メソッドを持っています。

できるだけ小さな要素に侵入することは良い習慣だと思います。 たとえば、ページにポップアップウィンドウが表示される場合は、このウィンドウ用に別のクラスを作成することをお勧めします。 断片化はすべて純粋で、アプリケーション自体に何かを反映する必要があります。

また、この記事で説明するアプローチでは、各メソッドは、可能な場合は常に、ページのコピーを返すことを前提としています。 たとえば、[ログイン]ボタンをクリックすると、メインページに移動します。 その結果、「ログイン」ボタンをクリックするメソッドは、メインページが記述されているクラスのインスタンスを返します。 メソッド内のアクションがどこにも行かない場合は、メソッドが配置されているページクラスのインスタンスを返します。

これにより、ページのメソッドに簡単にアクセスできます-

 loginPage. TypeUserName(userName). TypePassword(password). ClickLoginButton();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、TypeUserNameメソッドは他のページへの遷移をもたらさないため、このメソッドはLoginPageページのインスタンス（それが配置されているページ）を返します。 同じことがTypePasswordというメソッドにも当てはまります。 ただし、ClickLoginButtonメソッドはメインページに遷移するため、LandingPageクラスのインスタンスを返します。 メインページ（LandingPage）からメソッドを呼び出す必要がある場合は、ドット（。）を挿入するだけで、すぐにメインページのすべてのメソッドにアクセスできます。

例に戻りましょう。 システムにログインするページと、ログイン後に取得するページの2つのページがあります。

LoginPageクラスとLandingPageクラスを作成します。

システムにログインするページで、論理的に理解できる3つのアクション（テストの一環）を実行します。フィールドにユーザー名を入力し、フィールドにパスワードを入力してEnterボタンをクリックします。

取得するページでは、（テストの一環として）1つのアクションのみを実行します-ページの右上隅にユーザー名が正しく表示されることを確認します。

 public class LoginPage : TestFramework { [FindsBy(How = How.XPath, Using = USER_NAME_TEXT_FIELD)] public IWebElement userNameTextField; [FindsBy(How = How.XPath, Using = PASSWORD_TEXT_FIELD)] public IWebElement passwordTextField; [FindsBy(How = How.XPath, Using = LOGIN_BUTTON)] public IWebElement loginButton; public static LoginPage GetLoginPage(){...} public LoginPage TypeUserName(string userName){...} public LoginPage TypePassword(string password){...} public LandingPage ClickLoginButton(){...} public const string USER_NAME_TEXT_FIELD = "//input[@id='email']"; public const string PASSWORD_TEXT_FIELD = "//input[@id='pass']"; public const string LOGIN_BUTTON = "//label[@id='loginbutton']/input"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の例には、GetLoginPage（）メソッドがあります。 初期化された要素を持つこのページのクラスのインスタンスを返します。



また、ページで継承を使用することの便利さを強調したいと思います。 たとえば、ほとんどのWebアプリケーションでは、すべてのページに上部（ヘッダー）が表示されます。 この場合、Headerを別のクラスで記述し、他のすべてのページをこのクラスの相続人にすることが非常に便利です。 その後、ヘッダーメソッドはどのページからでも利用できます。

継承は、チェックボックスをクリックするとフォーム全体が表示される場合にも使用できます。 最大の装飾の原則に基づいて、このフォームを別のクラスに配置することをお勧めします。 しかし同時に、ページ自体のすべての要素は表示されたままでした。 ページの要素とメソッドが利用できるように、フォームをページの後継にすることをお勧めします。



ヘルパークラスのあるレイヤーなしでプロジェクトがビルドされるのをよく見ました。 直接アクセスされるページメソッドをテストします。

このアプローチには次の欠点があります。 自動化プロジェクトでは、いくつかのページの基本アクションを組み合わせるメソッドが必要です。 この例には、DoLogin（）というメソッドがあります。 完全には説明しませんでした。 正しく記述した場合、最初は誰もログインしていないことを確認し、ログインしている場合は終了して、ログインしているページに移動する必要があります。 この方法はさらに先に進み、完了後、メインページがロードされていることを確認する必要があります。 このアプローチの基本を簡単に伝えるために、これを実装しませんでした。

ただし、このメソッドをLoginPageページのクラスに配置すると（ヘルパークラスを持つレイヤーのないプロジェクトのように）、論理モジュール間のこの明確な境界が失われます。 結局のところ、ログイン手順はログインページではなく開始および終了します。

しかし、システムに入るためのフィールドの検証をチェックするためのより多くの方法が必要な状況を想像してください。 この場合、LoginPageクラスは、LoginTestsクラスのみが必要とする多数のメソッドで大きくなります。

ページクラスのこのような過剰な複雑なメソッドは、一方で基本メソッドの検索を複雑にし、他方で論理モジュール間の境界をあいまいにします。



しかし、ヘルパークラスの作成には1つの落とし穴があります。 1番目のクラスのテストで使用されるメソッドをどうするかは理解できます-それらはこのテストのヘルパークラスにあります。 しかし、他のテストクラスで使用できる他の複雑なメソッドをどうすればよいでしょうか？

ここでは、次のように進みます-複雑なメソッド（つまり、1つ以上のページクラスのいくつかの基本メソッドを使用するメソッド）を持つ個々のクラスを強調表示します。 名前のタイプはNavigationUtilsになります。 クラスの名前から、アプリケーション内を移動するためのメソッドが含まれていることは明らかです。 またはLoginUtils-システムに入るためのテストを含むクラスに加えて、他のクラスで使用できるログインメソッド。 さまざまなテストを実行するためにアプリケーションでコンテンツを作成する必要がある場合は、ContentUtilsクラスを作成できます。

私のルールは単純です-あるヘルパークラスのこのメソッドが、テストまたはヘルパークラスを持つ他のクラスに必要な場合、このメソッドは対応するUtilsクラスに移行します。 そのようなUtilsクラスがまだ作成されていない場合は、作成します。

このアプローチは、プロジェクトを追加のレイヤーで多少複雑にしますが、論理モジュール間に明確な境界線を置きます。 ページクラスには、このページでのみ実行できる最も基本的なメソッドのみが配置されるためです。

サービスについてもう少し。

私が参加したプロジェクトでは、ビルドからビルドへのアプリケーションの変更の大部分はロケーターから来ました。 別の小さな部分は、要素に影響を与える方法を説明しました（たとえば、以前は通常のClick（）コマンドで解決されていたものですが、新しいビルドがリリースされた後、MouseMove（）、MouseDownおよびMouseUp（）からの一連のコマンドが既に必要でした） そのような場合、すべてのサポートはページクラスの変更に帰着します。 そして、あなたが見るように、これらは最も再利用されたクラスです。 したがって、サポートの労力は最小限です。

新しいビルドでアクションの論理チェーンが変更された場合があります。たとえば、アプリケーションのエンティティに移動するためのリンクが、あるメニューから別のメニューに移動しました。 その後、サポートは既にヘルパークラスとUtilsクラスに影響します。

非常にまれに、テスト自体のロジックが変更された場合、テストでクラスをサポートする必要があります。

完全な構造。

私自身は、このようなプロジェクトの理想的な構造を推測しましたが、私はそれを追うことができず、努力することしかできなかったと告白します。



これは簡単なルールのセットです：

1.テストクラスは、ヘルパークラスとUtilsクラスのみを使用します。 ページクラス、特にSeleniumとWebdriverで動作するフレームワークメソッドは使用しません。 フレームワークの残りのメソッドを使用できます。

2.ヘルパークラスは、ページクラスとUtilsクラスのみを使用します。 SeleniumおよびWebdriverで機能するフレームワークメソッドは使用しません。 フレームワークの残りのメソッドを使用できます。

3. Utilsクラスはページクラスのみを使用します。 SeleniumとWebdriverで動作するヘルパークラスとフレームワークメソッドは使用しません。 フレームワークの残りのメソッドを使用できます。

4.ページクラスは、フレームワークメソッドのみを使用します。 SeleniumメソッドとWebdriverメソッドを直接使用しないでください。

このようなルールを最初に遵守することは、将来のプロジェクトでの苦痛な問題を回避するのに役立ち、サポートを可能な限り簡単にするでしょう。



私の観点からは、多くの既存のプロジェクトは、説明したアプローチに従ってやり直すことができます。 私自身もそのような経験をしました。 そして、そのような移行により、大量の重複したコードが明らかになりました。



自動化をテストするために大規模なプロジェクトに参加した人は、そこに秩序がなければ生き残れないことを理解しています。 したがって、まだ聞いていない、考えていない、試していない場合は、同じように試してみることをお勧めします。