在Page模式中，我们不是创建了比广义可重用函数更专业化的方法吗？

Question

背景:在硒自动化中，多年来我们都使用页面对象模式作为“最佳实践”。在Page中，“方法”与页面紧密耦合，而不是泛型上下文无关函数。根据我的观察，70-80%的Page objects方法代码不能在其他web应用程序中直接重用，因为每个页面对象方法都是对给定web应用程序中的特定页面高度专门化的。

我们还可以通过简单定义对象集合(对象存储库)和一组定义良好的操作操作的操作/实用程序函数来获得相同的抽象级别(如果不是更好的话)。

那么，使用页面对象模式的确切意义是什么，我们可以使用简单的函数，这些函数可以在不同的上下文中重复使用。那么，我们不是过度耦合页面对象中的东西了吗？

困境:从根本上说，我们可以在任何UI自动化中执行一些UI操作。当我们在页面的上下文中定义方法时，我们不是在创建专门的“方法”而不是广义的“上下文无关函数”吗？

例如:像“单击submit_user_button”这样的页面对象方法，它特定于一个页面，即使在其他页面中也不能直接重复使用！

我强烈认为，这让我们失去了flexibility=>reusability=>maintainability？

Answer 1

这不是pageObjects的本质吗:描述页面上的UI元素，以及如何与它们交互。

现在，在编写测试时，您通常会以某种方式与多个元素交互，以实现工作流。现在，如果多个测试使用相同的工作流，那么将工作流-步骤的组合也移动到pageObjects中可能是有意义的，因此其他测试可以重用它。我不会从这个开始的，只要保留它干的。

将所有UI元素及其交互拆分为页面和工作流，只会使您更容易阅读、理解如何和何时使用它们。

我真的不明白这怎么会让事情变得太复杂。创建抽象、解耦并将其存储在大约100行的文件中是程序员的谋生之道。

在创建pageObjects时，不要从一开始就过度设计它们。记住雅格尼原则。

关于出色的页面对象，我喜欢的是将浏览器的驱动程序与测试分离开来。测试与页面交互，页面与驱动程序交互。测试不认识司机。这意味着您可以将驱动程序从Selenium切换到Cypress，而无需在理论上更改测试。

Answer 2

页面对象在较小的站点中很好地工作，这些站点很少或根本不重复使用字段，因为耦合效应不足以引起重大问题--在可读测试、DRY、YAGNI和SOLID之间找到平衡总是有困难的。

我发现，一旦应用程序足够大，最好以输入类型对象的形式工作，这样测试代码就可以传递定位器信息和要输入的任何数据。

这大大简化了我的测试代码:我有一个对象来处理编辑类型的输入，另一个对象用于可单击字段(按钮、链接等)，另一个对象用于复选框，另一个用于下拉列表，等等。这允许我的页面对象是一个通用对象，它调用FindAndClick(string id)、FindAndEnterText(string id, string text)等方法(然后我将数据驱动测试，以便通过测试工具从CSV文件中读取I、文本等)。

Answer 3

PageObjects这个词已经被过度使用了(包括我)。

重置：

我们有元素定位器。

有时，我们的元素定位器也会对它们进行操作(例如单击)。

一些元素定位器位于页面级别，但其他元素定位器可以被认为是在片段、框架、工作流或域特定的分组级别上。

然后，这些定位器基本上可以通过两种方式访问--直接在测试脚本的顶层，例如click user_submit_button或您的自定义DSL (可能是submit_user_form )，然后函数submit_user_form本身有一行click user_submit_button，在下一个较低的页面对象和级别定义user_submit_button。

在任何一种情况下，页面对象服务的两个关键角色是：

• 减少因相同元素的重复定义而导致的错误
• 命名对象以使其更易读和更易于维护。

你想让代码读得更像

click submit_user_button

而不是像

click(find('div.users span#inputform button'))

是的，我们在这里创建的是非常具体和有选择性的函数，而不是一般函数，但在本例中，一般函数并不是编写这种特定测试代码的唯一目标。我们正在使代码可维护，这就是我们的目标。我见过没有使用Page对象的代码，它看起来很难看。