我们的团队正在讨论是否应禁止在我们的页面对象中公开“ElementFinder”和“ElementArrayFinder”。
主要原因是西蒙斯图尔特的引用。 Page Objects Done Right - selenium conference 2014 (page.7)
如果你的测试方法中有一个WebDriver API ......你做错了。
SeleniumHQ / selenium / PageObjects https://github.com/SeleniumHQ/selenium/wiki/PageObjects
对于返回另一个Page Object的转换函数或者如果在一个页面上发生多个选择，该方法是正确的，这样我们就可以返回Page并链接这些调用。
但是当我们做一些非常简单的事情时，有很多样板来编写测试元素存在并有文本。
创建“ElementFinder”的模拟函数对我来说没有多大意义。 大多数情况下，暴露元素的速度更快，更易读，并使用“ElementFinder”的内置函数，如“.getText（）”。你认为它更好的make元素是私有的，只暴露“getElementText（）”函数吗？
在禁止在页面对象中公开“ElementFinder”和“ElementArrayFinder”时，最佳做法是什么？
答案 0 :(得分：1)
我们使用黄瓜，所以测试分为
所有逻辑和断言都在步骤定义和帮助器中。当需要屏幕值时，步骤定义会调用页面方法。页面方法返回POJO s。有关查找元素的所有详细信息都封装在页面文件中。原因很明显;当（不是）页面HTML发生变化时，您只需要在一个地方进行修复。一旦打破封装，就会开始进行维护噩梦。
我经常使用的模式是创建一个辅助类，例如OfficeInfo，用于包含办公桌中tr的所有td。页面方法将返回
List<OfficeInfo>
即。每个tr的一个列表元素。现在，办公室信息与该信息在页面上的显示方式的细节分离。如果添加了新的td，则更新类OfficeInfo，更新页面方法并插入新的步骤定义，而不会影响使用OfficeInfo（但不使用新的td）的所有其他位置。