ruby - ページオブジェクトモデル: ページメソッドにアサーションを含めないのはなぜですか?

Question

初めてのポスター。私は長年 UI の自動化に取り組んできましたが、ページオブジェクトモデルを紹介されたり、ページオブジェクトモデルを使用するように指示されたりしたのはつい最近のことです。そのほとんどは常識であり、私がすでに使用している手法を含んでいますが、十分に合理的な説明を広範囲に検索したにもかかわらず、自分の心の中で正当化できなかった特定の細かい点があります. POM を自分のベストプラクティスと統合しようとしているときに、この質問が驚きを引き起こしたので、ここの誰かが私を啓発してくれることを願っています。

http://code.google.com/p/selenium/wiki/PageObjectsから:

上記のコードは重要なポイントを示しています。ページの状態に関するアサーションは、PageObjects ではなく、テストが行う必要があります。もちろん、すべてのガイドラインと同様に、例外もあります。

http://seleniumhq.org/docs/06_test_design_considerations.html#chapter06-referenceから:

ページオブジェクトの設計方法には多くの柔軟性がありますが、テストコードの望ましい保守性を実現するための基本的なルールがいくつかあります。ページオブジェクト自体は、検証やアサーションを行うべきではありません。これはテストの一部であり、ページオブジェクトではなく、常にテストのコード内にある必要があります。ページオブジェクトには、ページの表現と、メソッドを介してページが提供するサービスが含まれますが、テスト対象に関連するコードはページオブジェクト内にあるべきではありません。

ページオブジェクト内に含めることができ、またそうすべきである単一の検証があり、それは、ページ、およびおそらくページ上の重要な要素が正しく読み込まれたことを検証することです。この検証は、ページオブジェクトのインスタンス化中に行う必要があります。

これらの「ガイドライン」はどちらも潜在的な例外を認めていますが、基本的な前提には同意できませんでした。私は「ページメソッド」内でかなりの量の検証を行うことに慣れており、検証の存在は、さまざまなコンテキストで問題を見つけるための強力な手法だと思います (つまり、メソッドが呼び出されるたびに検証が行われます)。特定のテストの限られたコンテキストでのみ発生するよりも。

たとえば、AUT にログインしたときに、「ユーザーとしてログインしました」というテキストが表示されたとします。単一のテストでこれを明確に検証することは適切ですが、毎回検証したくないのはなぜですかログインが呼び出されますか？このアーティファクトは、ページが「正しくロードされた」かどうかに直接関連するものではなく、一般的に「テストされているもの」には関連していないため、上記の POM ガイドラインによれば、明らかにページメソッドに含めるべきではありません。 ..しかし、可能な限り前もって考えずに、重要なアーティファクトを可能な限り頻繁に検証することにより、自動化の力を最大化するために、明らかにそこにある必要があるように思えます。検証コードをページメソッドに入れると、テストで心配することなく「無料で」多くの検証を取得できるため、自動化の力が倍増します。さまざまなコンテキストでのこのような頻繁な検証により、見つけられない問題が見つかることがよくあります。たとえば、検証がそのアーティファクトの単一のテストに限定されている場合。

言い換えれば、私はテスト固有の検証と「一般的な」検証を区別する傾向があり、後者が広範囲にページメソッドに含まれることは完全に適切/望ましいと思います。これにより、より薄いテストとより厚いページオブジェクトが促進され、一般に、これらのガイドラインでは反対の競合が存在するにもかかわらず、より多くのコードを再利用することでテストの保守性が向上します。私は要点を逃していますか？ページメソッドで検証を望まない本当の理由は何ですか? 私が説明した状況は実際にこれらのガイドラインで説明されている「例外」の 1 つであり、したがって実際には POM と矛盾していませんか? ご意見ありがとうございます。-jn-

score 37 · Accepted Answer

ガイドラインとして、アサーションはページオブジェクトではなくテストで実行する必要があります。もちろん、これが実際的なアプローチではない場合もありますが、上記のガイドラインが正しいと言えるほどまれな場合もあります。ページオブジェクトにアサーションを含めるのが嫌いな理由は次のとおりです。

verifyアサーションがページオブジェクトの別の場所に埋め込まれているメソッドを呼び出すだけのテストを読むのは非常にイライラします。可能であれば、テストが何を主張しているのかを明確にする必要があります。これは、アサーションがテストに直接含まれている場合に最適です。アサーションをテストの外のどこかに隠すと、テストの意図があまり明確になりません。
ブラウザーテストでのアサーションはコストがかかる可能性があります。テストが非常に遅くなる可能性があります。数百または数千のテストがある場合、テストの実行時間に数分/時間が追加される可能性があります。これは悪いことです。アサーションを特定のアサーションに関係するテストだけに移動すると、テストがはるかに高速になり、関連する欠陥を引き続き検出できることがわかります。質問には次のものが含まれていました。

ページメソッドに検証コードを入れると、自動化のパワーが倍増し、多くの検証を「無料」で取得できるようになります

まあ、「自由は無料ではない」:)実際に増加しているのは、テストの実行時間です。
いたるところにアサーションがあると、別の優れたガイドラインに違反します。「テストごとに 1 つのアサーション」( http://blog.jayfields.com/2007/06/testing-one-assertion-per-test.html )。私はそれに宗教的に固執しませんが、原則に従うようにしています. 可能であれば、テストは 1 つのことにのみ関心を持つべきです。
1 つのバグが原因で多くのテストが失敗し、テストすべきものをテストできなくなるため、テストの価値が低下します。

たとえば、AUT にログインしたときに、「ユーザーとしてログインしました」というテキストが表示されたとします。単一のテストでこれを具体的に検証することは適切ですが、ログインが呼び出されるたびに検証したくないのはなぜですか?

ページオブジェクトクラスにアサーションがあり、予想されるテキストの変更がある場合、ログインするすべてのテストが失敗します。代わりにアサーションがテスト内にある場合、1 つのテスト (正しいメッセージを明確にテストするテスト) のみが失敗し、他のすべてのテストは実行を継続して他のバグを検出します。ログインメッセージが間違っていることを伝えるのに 5,000 回のテストは必要ありません。1回のテストで十分です;）
クラスに複数のことをさせることは、SOLIDの「S」に違反します。つまり、「単一責任の原則」( SRP) に違反します。クラスは 1 つのことだけを担当する必要があります。この場合、ページオブジェクトクラスは、ページ (またはそのセクション) のモデル化のみを担当する必要があります。それ以上のことを行う場合 (例: アサーションを含む)、SRP に違反しています。

score 12 · Accepted Answer

私もこの推奨事項に時々苦労しました。このガイドラインの背後にある理由は、ページオブジェクトを再利用可能にしておくことであり、ページオブジェクト内に assert を配置すると、関連のない多数のテストで assert を再利用する能力が制限される可能性があると思います。そうは言っても、ヘッダーのキャプションをテストするなど、特定の検証方法をページオブジェクトに配置しました。これは、変更されないページの要素のテストロジックをカプセル化するためのより良い方法です。

別のメモ - ドメインモデルがページオブジェクトとして再利用されている MVC アプリケーションを見てきました。これを正しく行うと、テストライブラリの冗長コードを大幅に減らすことができます。このパターンでは、ビューモデルはテストフレームワークへの参照を持たないため、明らかに、ビューモデルにアサートを配置することはできません。

score 6 · Accepted Answer

ページオブジェクトはアサーションを実行すべきではありません。これは、ページオブジェクトがテストフレームワークについて認識している必要があるためです (組み込み言語アサーションを使用している場合を除く)。ただし、要素を見つけてアクションを実行するには、ページの状態を知る必要があります。

重要なのは、「もちろん、すべてのガイドラインと同様に例外があります...」というステートメントにあります。

ページは、アサーションを実行するのではなく、例外をスローする必要があります。そうすれば、テストはアサーションをキャッチし、それに応じて保釈または行動することができます。例えば。

page = ProfilePage.open
try 
  page.ChangePassword(old, new)
catch notLoggedIn
  page.Login(user, pass)

assert page.contains "your password has been updated"

この限られた例では、何度も何度も確認する必要があるため、最善の方法ではないかもしれませんが、アイデアは得られます。状態を確認することもできます（2回）

if page.hasLoginDialog
  page.Login

if page.hasLoginDialog //(again!)
  assert.fail("can't login")

プロフィールページがあることを確認することもできます

try 
  page = site.OpenProfilePage
catch notOnProfilePage

または必要な要素があります profilepage.changePassword(old,new) catch elementNotFound を試してください

または例外をスローせずに

page = site.OpenProfilePage
if ! page instanceof ProfilePage

または複雑なチェック

assert page.looksLikeAProfilePage

重要なのはやり方ではありません。テストのロジックを最小限に抑えたいが、ページオブジェクトをテストフレームワークに結び付けたくない場合 - 結局のところ、同じオブジェクトをスクレイピングやデータ生成に使用したり、別のテストで使用したりする可能性があります。独自のアサーションを持つフレームワーク。

必要に応じて、アサーションをテストケースからテストヘルパーメソッドにプッシュできます。

page = site.GoToProfilePage
validate.looksLikeProfilePage(page)

言語が mixin をサポートしている場合、これは mixin の絶好の機会です。そのため、きれいなページオブジェクトを保持し、健全性チェックを mixin できます。

score 4 · Accepted Answer

同じアサーションが複数のテストメソッドで使用される可能性があることを知ったとき、これは私を困惑させます。たとえば、アサーション固有のメソッドを書く -

public PaymentPage verifyOrderAmount(BigDecimal orderAmount) {      
   Assertion.assertEquals(lblOrderAmount.getText(), orderAmount, "Order Amount is wrong on Payment details page"); 
   return this; 
}

これで、必要なすべてのテストで再利用できます。複数のシナリオを扱う複数のテストで同じアサーションステートメントを繰り返す代わりに。言うまでもなく、テストに応じてメソッドで複数のアサーションを連鎖させることができます。

 .verifyOrderAmount(itemPrice)
 .verifyBankAmount(discountedItemPrice)
 .verifyCouponCode(flatDiscountCode.getCouponCode())

ページオブジェクトがページによって提供されるサービスを表すと想定される場合、アサーションポイントもページによって提供されるサービスではないでしょうか。

score 3 · Accepted Answer

@Mattがページオブジェクトでドメインモデルを再利用することで時間を節約できるかもしれませんが、テストの匂いではありません。テストロジックはドメインモデルを十分に明確にしています（何を達成しようとしているかによって異なります）。

元の質問に戻ります。本当にPageObjectでアサーションを実行する必要がある場合は、isLoaded（）メソッドを使用できるselenium loadablecomponent <>を使用するか、loadablecomponent<>クラスにカスタムアサーションを含めることができます。これにより、ページオブジェクトにアサーションがなくなりますが、ロード可能なコンポーネントでアサーションを実行できます。以下のリンクを参照してください...

https://github.com/SeleniumHQ/selenium/wiki/LoadableComponent

_夢想家

score -1 · Accepted Answer

私は著者にこれ以上同意できませんでした。

テストメソッドにアサーションを追加すると、「早期に失敗」するのに役立ちます。アサーションとは、ボタンをクリックした後に特定のページが読み込まれたかどうかなどを確認することを意味します (いわゆる一般的なアサーション)。

実行時間がそれほど長くなるとは本当に思いません。UI の自動化はデフォルトでは遅いため、数ミリ秒のチェックを追加してもそれほど大きな違いはありませんが、トラブルシューティングが容易になり、初期の障害が報告され、コードが再利用しやすくなります。

ただし、UI テストの種類によっても異なります。たとえば、エンドツーエンドテストを大部分が正のパスで実装している場合、テストメソッド内で、ボタンをクリックすると実際にページが開くことを確認することは理にかなっています。ただし、ネガティブなシナリオをたくさん書いている場合は、必ずしもそうとは限りません。

ruby - ページ オブジェクト モデル: ページ メソッドにアサーションを含めないのはなぜですか?

6 に答える 6

Related

Reference

ruby - ページオブジェクトモデル: ページメソッドにアサーションを含めないのはなぜですか?