为什么使用页面工厂？

Question

我是一名新的测试工程师，一直在阅读页面对象模型并实现它们，并不断遇到页面工厂。我知道页面工厂是一个POM，它提供了额外的功能，例如在调用页面工厂时实例化所有元素，以及更可读的测试代码（尽管我不完全赞同可读性）。明确地说，我对POM很感兴趣。代码的可重用性和相对容易的维护非常好，我正在朝着这个方向努力。

我要回答的两个问题是：

• 为什么我要实例化所有元素，而不是动态地进行

Answer 1

为什么我想实例化所有的元素，而不是在运行中？

如果我没记错的话，PageFactory会扫描任何WebElement属性/字段及其属性，并用代理将它们包装起来。此时您还没有接触Selenium服务器（您可以在服务器控制台输出中检查这一点）。尝试访问属性后，WebElement将被实例化。因此，如果您只访问了一个PO属性/字段，则只会创建一个WebElement。

页面工厂的优势是什么，我没有看到？

属性的使用使代码更具可读性，也更容易生成。创建一个为您生成PageObject的工具是很常见的。

PageFactory是为了支持PageObject模式而创建的，仅此而已。你不一定要使用它才能走这条路。

最后，如果您对它的详细工作方式感到好奇，我建议您检查源代码。这是我刚开始使用硒时做的。

Answer 2

有几个答案说PageFactory在实例化时“加载”了所有的网络元素——这实际上是不正确的。

直到您访问这些元素，它们才会加载。它是通过基类和RealProxy完成的。它确实在引擎盖下使用了标准的FindElement（s）By方法，所以使用WebElements相对于存储By并在需要时加载它们并没有真正的性能优势。

我选择不使用PageFactory模型的一个原因是，我可能会搜索一个我不想存在的元素，通过使用自动连线方法，它会在我可以在测试中说“不存在”之前搜索它是否存在。

另一个问题是PageFactory如何实例化WebElement和如何驱动程序之间存在细微差异。FindBy实例化它们。让我感到困扰的是，PageFactory的版本没有实现IWrapsDriver，这意味着您无法获得用于从元素中查找元素的驱动程序。这可能看起来不多，但这意味着当你想要编写WebElement方法的扩展，而这些扩展又需要一个驱动程序时，你必须找到一种（更复杂的）获取驱动程序的方法，尤其是因为我认为PageObjectModel不应该有一个直接提到司机...

但也就是说，在很多情况下，开箱即用的PageFactory方法是非常好的。我认为，使用或不使用PageFactory的关键在于对测试代码和页面对象模型如何工作和相互作用有一个一致的方法，因为这是可维护性的关键。

Answer 3

下面是西蒙·斯图尔特，2017年奥斯汀SeleniumConf大会上硒项目负责人和页面工厂创始人。在他的主题演讲中，他说不要使用PageFactory。本节演讲从这里开始：

https://youtu.be/gyfUpOysIF8?t=1517

实际报表是27:25。