页面对象模式和替代方案 [英] Page Object pattern and alternatives

问题描述

当您自动化 Web UI 测试时，您希望组织测试，以便它们可维护并尽可能减少代码重复.页面对象模式即将到来.p>

您在现实世界的项目中尝试过吗?有没有其他选择?您如何为复杂的网站建模(很少有嵌套的母版页、弹出窗口、带有疯狂验证的大型表单)?我对一般模式以及特定情况(Selenium/ASP.NET MVC/NUnit)感兴趣.

解决方案

你问了很多问题，我试着回答几个.

我在使用 Selenium 的 Web 应用程序和桌面 WinForms 应用程序中使用了 Page Object(虽然这不是严格的 Page Object，但我以相同的方式使用它——也许是 View Object?).我的结论是它效果很好，我肯定会推荐它.

下面是一个简短的示例，说明测试的外观，我们编写它的方式:

[测试]公共无效 AccountPageNameIsLoggedInUsersName(){FirstPage()//返回第一页.LoginAs("tobbe", "s3cr3t")//返回 LoggedInPage.ClickOnMyAccount()//返回 MyAccountPage.AssertThat(p => p.Name, Is.EqualTo("tobbe"));//p 是 MyAccountPage 类型}

这里，Selenium 魔法被放置在 FirstPage() 方法和页面中.这样你就可以从测试中隐藏所有不必要的实现细节.我想你可以弄清楚这些方法是如何实现的.

将 Selenium 内容隐藏在页面中的一个好处是，您可以在不更改测试的情况下将其转换为例如一个 Model-View-Presenter 测试，其中 PageObject 代表视图(这类似于我在 WinForms 应用程序中所做的).

关于母版页，我们所做的就是用接口装饰页面并在这些接口上创建扩展方法:

公共类 LoggedInPage : Page, IMainMenuHolder { ... }公共静态类 MainMenuHolderExtensions{public static MyAccountPage ClickOnMyAccount(this IMainMenuHoder me) { ... }}

When you automate web UI testing you want to organize your tests so that they are maintainable and code duplication is minimized as possible. On of the way to go is Page Object pattern.

Did you try it in real world projects? Are there any alternatives? How do you model complex sites (few nested master pages, popups, large forms with crazy validations)? I'm interested in general patterns as well as in specific cases (Selenium/ASP.NET MVC/NUnit).

解决方案

You've asked quite a lot of questions, I'll try to answer a few of them.

I've used Page Object in a web app using Selenium and also in a desktop WinForms app (while that's not strictly Page Object, I've used it in the same way -- View Object, perhaps?). My verdict is that it works great and I'd definately recommend it.

Here's a short example of what a test might look like, the way we wrote it:

[Test]
public void AccountPageNameIsLoggedInUsersName()
{
    FirstPage() // Returns FirstPage
        .LoginAs("tobbe", "s3cr3t") // Returns LoggedInPage
        .ClickOnMyAccount() // Returns MyAccountPage
        .AssertThat(p => p.Name, Is.EqualTo("tobbe")); // p is of type MyAccountPage
}

Here, the Selenium magic is placed inside the FirstPage() method and the pages. This way you hide all the unnecessary implementation details from the test. I guess you can figure out how the methods are implemented.

A bonus from hiding the Selenium stuff inside the pages is that you could, without changing the test, convert it into e.g. a Model-View-Presenter test where the PageObject represents the view (that's similar to what I did in the WinForms app).

Regarding master pages, what we did is that we decorated the pages with an interface and created extension methods on those interfaces:

public class LoggedInPage : Page<LoggedInPage>, IMainMenuHolder { ... }

public static class MainMenuHolderExtensions
{
    public static MyAccountPage ClickOnMyAccount(this IMainMenuHoder me) { ... }
}

这篇关于页面对象模式和替代方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！