Selenium [Java] PageFactory设计:在页面对象模型之后我在哪里编写断言 [英] Selenium [Java] PageFactory Design : Where do I write my Assertions following Page Object Model

查看:133
本文介绍了Selenium [Java] PageFactory设计:在页面对象模型之后我在哪里编写断言的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在关注Page Object Model以在一个应用程序中自动化流程。在其中一个模块中,我必须断言页面标题和更多消息。截至目前,我将我的Assertion代码放在​​PageFactory中,如下所示:

I am following Page Object Model to automate a flow in one application. In one of the module I have to assert Page Title and some more messages. As of now I am putting my Assertion code in the PageFactory itself as follows:

public class EditPost {

    WebDriver driver;

    public EditPost(WebDriver editPostDriver)
    {
        this.driver=editPostDriver;
    }

    @FindBy(how=How.XPATH,using="//*[@id='message']/p")
    WebElement post_published;

    public void assert_message()
    {
        String actual_message_title=post_published.getText();
        Assert.assertEquals(actual_message_title, "Post published. View post");
        System.out.println("Message: Post published, Successfully Verified");
    }
}

我从主文件实现中调用断言方法TestNG如下:

I am calling the assert methods from the main file implementing TestNG as follows:

@Test (priority=5)
public void assert_message()
{
    //Created Page Object using Page Factory
    EditPost edit_post = PageFactory.initElements(driver, EditPost.class);
    edit_post.assert_message();

}

目前,我正在通过3个包执行执行。用于浏览器工厂的帮助程序包,用于PageFactories的Pages包和用于测试用例的Testcase包。

Currently, I am running the execution through 3 packages. "Helper" package for the Browser Factory, "Pages" package for the PageFactories and "Testcase" package for the Testcases.

我的目标是继续前进我想重用代码为所有不同的实用程序编写。

My objective is moving forward I want to reuse the code written for all the different utilities.

我的问题是:


  1. 根据PageFactory&的概念页面对象模型是我的方法正确吗?或者我是否需要将断言移动到助手包中?或者我应该为断言创建单独的库/包吗? (在新的日子里,我可能需要在一个页面上执行多个断言)

  1. As per the concept of PageFactory & Page Object Model is my approach correct? Or do I need to move the Assertions to the "Helper" package? Or should I create a separate library/package for the Assertions? (In the comming days I may need to perform multiple Assertions on a single page)

在下一个sprint中,我可能需要做一些其他活动,比如取屏全部/失败的测试用例的镜头。那么我如何保持设计的结构和组织,以便我可以重用代码/库/以最佳方式利用它们?

In the next sprint I may require to do some other activities like taking Screen Shots of All/Failed Testcases. So how do I keep my design structured and organized so I can reuse the code/libraries/utilize them in a optimum way?


推荐答案

根据我见过的大多数网站,最佳做法是将断言保留在页面对象之外。下面的一个例子来自Selenium文档。

Best practice, according to most sites I've seen, is to keep the asserts out of the page objects. One example is below from the Selenium docs.

http://www.seleniumhq.org/docs/06_test_design_considerations.jsp#page-object-design-pattern

页面对象的设计方式有很多灵活性,但是有一些基本规则可以获得测试代码所需的可维护性。

There is a lot of flexibility in how the page objects may be designed, but there are a few basic rules for getting the desired maintainability of your test code.

页面对象本身不应该进行验证或断言。这是测试的一部分,应始终位于测试代码中,永远不应位于页面对象中。页面对象将包含页面的表示,以及页面通过方法提供的服务,但是没有与测试内容相关的代码应该在页面对象中。

Page objects themselves should never make verifications or assertions. This is part of your test and should always be within the test’s code, never in an page object. The page object will contain the representation of the page, and the services the page provides via methods but no code related to what is being tested should be within the page object.

有一个单一的验证可以而且应该在页面对象中,即验证页面以及页面上可能的关键元素是否已正确加载。应在实例化页面对象时完成此验证。在上面的示例中,SignInPage和HomePage构造函数都检查预期的页面是否可用并为测试请求做好准备。

There is one, single, verification which can, and should, be within the page object and that is to verify that the page, and possibly critical elements on the page, were loaded correctly. This verification should be done while instantiating the page object. In the examples above, both the SignInPage and HomePage constructors check that the expected page is available and ready for requests from the test.

页面对象应返回产品名称,产品价格,当前选定数量等内容。然后测试代码断言返回的字符串与预期的匹配。

The page object should return things like product name, product price, currently selected quantity, and so on. The test code would then assert that the returned string matches what is expected.

assert_message()将变为 getMessage()并以 String 的形式返回消息。见下文。

assert_message() would become getMessage() and return the message as a String. See below.

public String getMessage()
{
    return driver.findElement(messageLocator).getText();
}

(注意:请继续阅读为什么我更改了 PageFactory 元素到这里的定位器。)

(NOTE: read on for why I've changed the PageFactory element to a locator here.)

然后在你的测试代码中你会有

and then in your test code, you would have

Assert.assertEquals(editPost.getMessage(), "Post published. View post");

现在,您已将断言代码保留在测试脚本中并且不在页面对象中。

Now you've kept the assert code in your test script and out of the page object.

查看您的代码,我会提出一些进一步的建议。

Looking at your code, I would make some further recommendations.


  1. 我建议你阅读一些Java命名约定。有很多站点都有建议,我认为它们之间有很多相似之处,但这里是 oracle建议开始。你的方法名应该是

  1. I would suggest you read up on some Java naming conventions. There are a number of sites that have recommendations and I think there are a lot of similarities between them but here's the oracle recommendations to start with. Your method names should be


动词,大小写混合,首字母小写,每个内部单词的首字母大写。

verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.

所以 assert_message()会变成 assertMessage() 等等。 _s使它看起来更像python。

So assert_message() would turn into assertMessage() and so on. The _s make it look more like python.

定位器的首选项顺序:ID,CSS选择器,在极少数情况下,XPath。 ID应始终是您的首选,因为它(通过W3C定义)在页面上应该是唯一的。 CSS选择器应该是下一个,因为它是最快的(在我的测试中比ID更快),具有最佳的浏览器支持,并且在浏览器中最一致地实现。 XPath应仅保留给CSS seletors无法完成的事情,例如通过包含文本查找元素。与CSS选择器相比,XPath定位器的性能较差,并且与CSS选择器的支持级别不同。例如,您的XPath定位器可以很容易地转换为CSS选择器#message> p。

Order of preference for locators: ID, CSS selector, and in rare circumstances, XPath. ID should always be your first choice because it (by W3C definition) should be unique on the page. CSS selector should be next because it's the fastest (in my testing faster than ID), has the best browser support, and is most consistently implemented across browsers. XPath should be reserved only for things that cannot be done by CSS seletors like finding an element by contained text. XPath locators are poor performers compared to CSS selectors and do not have the same level of support as CSS selectors. For example, your XPath locator can easily be converted to a CSS selector, "#message > p".

这里有一些CSS选择器引用可以帮助您入门。

Here are some CSS selector references to get you started.

CSS Selectors参考

CSS选择提示

删除 PageFactory 。是的,它似乎使事情变得更容易,但我认为在许多情况下它会导致更多问题,例如过时的元素异常等。而是根据需要刮取页面。声明类顶部的所有定位器,并在需要时在方法中使用它们。

Drop PageFactory. Yes, it seems to make things easier but I think in many situations it causes more problems, like stale element exceptions and the like. Prefer instead to scrape the page as needed. Declare all locators at the top of the class and use them in methods when needed.

public class EditPost {

    WebDriver driver;

    By messageLocator = By.cssSelector("#message > p")

    public EditPost(WebDriver editPostDriver)
    {
        this.driver = editPostDriver;
    }

    public String getMessage()
    {
        return driver.findElement(messageLocator).getText();
    }
}


我知道这比你提出的要多,但希望它有用。

I know this is more than you asked but hopefully it's helpful.

这篇关于Selenium [Java] PageFactory设计:在页面对象模型之后我在哪里编写断言的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆