第一次海报.我已经在UI自动化领域工作了很多年,但最近才引入/指示使用Page Object Model.其中大部分是常识,包括我已经使用的技术,但有一个特别好的点我无法在自己的脑海中证明,尽管广泛搜索了一个合理的解释.我希望这里有人可以启发我,因为这个问题引起了一些惊愕,因为我试图将POM与我自己的最佳实践相结合.
来自http://code.google.com/p/selenium/wiki/PageObjects:
上面给出的代码显示了一个重要的观点:测试而不是PageObjects应该负责对页面状态进行断言....当然,正如每个指南都有例外......
来自http://seleniumhq.org/docs/06_test_design_considerations.html#chapter06-reference:
在如何设计页面对象方面有很多灵活性,但是有一些基本规则可以获得测试代码所需的可维护性.页面对象本身永远不应该进行验证或断言.这是测试的一部分,应该始终在测试代码中,而不是在页面对象中.页面对象将包含页面的表示形式,以及页面通过方法提供的服务,但是没有与正在测试的内容相关的代码应该在页面对象中.
有一个单一的验证可以而且应该在页面对象中,即验证页面以及页面上可能的关键元素是否已正确加载.应在实例化页面对象时完成此验证.
这两个"指南"都允许潜在的例外,但我对基本前提不能不同意.我习惯于在"页面方法"中进行大量的验证,我认为验证的存在是一种强大的技术,可以在各种环境中查找问题(即每次调用方法时都会进行验证)而不仅仅发生在特定测试的有限环境中.
例如,让我们想象一下,当您登录AUT时,会出现一些文本"以USER身份登录".有一个测试专门验证这个是合适的,但为什么不想在每次调用登录时验证它？这个工件与页面"是否正确加载"没有直接关系,并且它与"正在测试的内容"无关,因此根据上面的POM指南,它显然不应该是页面方法. ..但在我看来,它显然应该存在,通过尽可能经常地验证重要的工件来最大化自动化的力量,尽可能少的事先考虑.将验证码放入页面方法可以增加自动化的功能,允许您"免费"获得大量验证,而不必在测试中担心,并且在不同的环境中进行频繁验证通常会发现您不会发现的问题如果验证仅限于对该工件的单个测试.
换句话说,我倾向于区分特定于测试的验证和"一般"验证,并且我认为后者被广泛地包含在页面方法中是完全合适/可取的.这促进了更薄的测试和更厚的页面对象,这通常通过重用更多代码来提高测试可维护性 - 尽管这些指南中存在相反的争用.我错过了这一点吗？不希望在页面方法中进行验证的真正原理是什么？我所描述的情况实际上是这些指南中描述的"例外"之一,因此实际上与POM不一致吗？提前感谢您的想法.-jn-