页面对象模型中的缺陷？

Question

我读过这篇关于Page /POM缺陷的文章，作者是ThoughtWorks - https://blog.getgauge.io/are-page-objects-anti-pattern-21b6e337880f的一位女士。

她说POM会导致过多的代码和可维护性问题。例如，她违背了关于Page Objects/POs应该返回其他POs的一般建议--参见标题“方法链接”下的内容。

这些论点是否合理？POM有什么真正的缺陷吗？

Answer 1

我认为，如果你坚持简单的马丁·福勒描述的网页，它是好的。它应该是一个简单的抽象，以保持您的测试代码干的，可重用，并通过使用描述页面/视图行为的页面方法来增加可读性。

链接的文章主要是关于页面工厂的问题，并且认为PageObjects必须返回另一个页面(它们不是，但有时非常方便！)就我个人而言，我从未见过PageFactories的用途，他们做的是我不需要的魔术，冗长的，等等。我也不认为需要一个额外的步骤层，建议的规范添加。对我来说，这是类似的开销，也带来了其他的痛苦。

只要保持简单，并且只在你需要的时候增加复杂性。

Answer 2

我不会详细讨论页面对象的问题，网上有很多文章是由那些投入比我更多思想的人写的。不过，根据我的经验，我会用https://johnfergusonsmart.com/beyond-page-objects-liberate-chains-ui-think/的话说:页面对象很好，但是另一个抽象级别像剧本模式一样有帮助。

简而言之:是的，论点是合理的，也有缺陷。页面对象仍然有其存在的理由来学习，并作为更好的模型的垫脚石。

Answer 3

结论是

她说POM会导致过多的代码和可维护性问题。

是错的。

页面对象是一个可以通过多种方式实现的概念。

它们解决了两个简单的问题：

• 他们减少复制干燥通常是好的
• 他们把命名为计算机科学中的两个难题之一

它们减少了可维护性问题--与您列出的要点之一完全相反。

我认为一个简单的例子可以说明这两个方面：

我将使用伪码。

没有页面对象

find ('div#main_content input#name').click   #for focus
fill_in('div#main_content input#name'), with: 'Bob'
expect(find('div#main_content input#name')).to have_Value 'Bob'

使用Page对象

name = div#main_content input#name # probably done in a setup file

find(name).click
fill_in(name), with: 'Bob'
expect(find(name)).to have_value 'Bob'

对我来说，第二条似乎更易读懂。

此外，如果定位器更改，则两者都需要更改，但在第二种情况下，此更改仅位于一个位置，而在第一种情况下，需要更新3个不同位置的定位器。