なぜPageFactoryを使用するのですか？
私は新しいテストエンジニアであり、ページオブジェクトモデルについて読んでそれらを実装し、ページファクトリに出くわし続けています。 Page Factoryは、Page Factoryを呼び出すときにすべての要素をインスタンス化するなどの追加機能や、テスト用のより読みやすいコードを提供するPOMであることを理解しています（ただし、読みやすさについては完全には売り切れていません）。明確にするために、私はPOMで販売されています。コードの再利用性とメンテナンスの比較的容易さは素晴らしく、私はその方向に構築しています。
私が思いついた2つの質問：
- その場で行うのではなく、すべての要素をインスタンス化したいのはなぜですか？
- 私が見逃しているPageFactoryの利点は何ですか？
オースティンで開催された2017SeleniumConfで、Seleniumプロジェクトリーダーであり、PageFactoryの作成者であるSimonStewartです。基調講演の中で、彼はPageFactoryを使用しないように言っています。講演のこのセクションはここから始まります。
https://youtu.be/gyfUpOysIF8?t=1517
実際の声明は27:25です。
PageFactoryがインスタンス化されるときにすべてのWebElementを「ロード」するという回答がいくつかありますが、これは実際には正しくありません。
要素は、アクセスするまで読み込まれません。これは、基本クラスとRealProxyを介して行われます。内部では標準のFindElement(s)Byメソッドを使用するため、WebElementを使用することと、Byを保存して必要なときにロードすることには、パフォーマンス上のメリットはありません。
PageFactoryモデルを使用しないことを選択した理由の1つは、do n'tが存在したい要素を検索し、自動配線を使用することです。アプローチでは、テストで「存在しない」と言う前に、存在するかどうかを検索します。
もう1つの問題は、PageFactoryがWebElementをインスタンス化する方法とDriver.FindByがそれらをインスタンス化する方法に微妙な違いがあることです。私を悩ませているのは、PageFactoryのバージョンがIWrapsDriverを実装していないことです。つまり、要素から要素を見つけるために使用されるドライバーを取得できません。これはそれほど多くないように思われるかもしれませんが、ドライバーを必要とするWebElementメソッドの拡張機能を作成する場合、特にPageObjectModelが必要であると私が信じているため、ドライバーを取得する（はるかに複雑な）方法を考え出す必要があります。ドライバーへの直接参照がありません...
とはいえ、多くの場合、すぐに使用できるPageFactoryアプローチは非常に優れています。 PageFactoryを使用する、または使用しないための鍵は、テストコードとページオブジェクトモデルがどのように機能し、相互作用するかについて一貫したアプローチをとることであると思います。それが保守性の鍵であるためです。
その場で行うのではなく、すべての要素をインスタンス化したいのはなぜですか？
私の記憶が正しければ、PageFactoryはWebElementのプロパティ/フィールドとその属性をスキャンし、プロキシでラップします。その時点では、まだSeleniumサーバーに触れていません（これはサーバーコンソールの出力で確認できます）。プロパティにアクセスしようとすると、WebElementがインスタンス化されます。したがって、1つのPOプロパティ/フィールドにのみアクセスした場合、その1つのWebElementが作成されます。
私が見逃しているPageFactoryの利点は何ですか？
属性を使用すると、コードがはるかに読みやすくなり、生成も簡単になります。 PageObjectsを生成するツールを作成するのが一般的です。
PageFactoryは、PageObjectパターンをサポートするために作成されました。 POの道を進むために、必ずしもそれを使用する必要はありません。
最後に、それがどのように詳細に機能するかについて興味がある場合は、ソースコードを確認することをお勧めします。それは私がSeleniumを始めたばかりのときにしたことです。