Hot answers tagged

13

I find the Page Object pattern very useful, and use a modified PageFactory (parameterized for custom timeouts). I also use WidgetObjects (basically, PageObjects with a parent reference via constructor) to represent common themes across pages. I don't think URL association is necessary on all pages, so I keep it out of my base class. URL params? I keep ...


6

PageObjects The code of automated test cases should be easy to understand and not too complex. If a test fails, we want to know why and this as soon as possible. To allow this exists PageObjects. PageObjects are classes that contains WebElements and every actions associated with those. A PageObject looks like this: class HomePage { WebDriver driver; ...


6

My first advice is to not write automated tests for pages that change frequently. You may be better off testing those pages manually. If you insist on automation, think about which aspects of the pages do not change, and write classes to model those aspects. For example, if forms always consist of text fields and a submit button, you can write a class to ...


6

No. Do not just split your pageObject into pageObject2, 3, 4, etc. This goes for all programming - split your classes logically by function, not arbitrarily! Your page object should be the source of truth for that specific page. When you start trying to interact with your page, does it really make sense that you should search between MyForm.java and MyForm2....


5

Advantages: Clear separation between test code and navigation code in code base. Easy to comprehend test, for example - Homepage.testLogin(username, password); is more succinct than selenium.type(username); selenium.type(password); selenium.click(submit); selenium.waitForpageToLoad(waitPeriod); Ease of maintenance, when UI changes you need to change ...


5

Read this ( scroll down to the page objects section though the whole page us good ) and this for some background Or from this page Taking it back to basics, essentially there are three functions I see a page object pattern provides: Ability to easily instantiate pages in a consistent manner Ability to concisely describe elements on a page, ...


5

In my opinion, yes, it does. However there isn't really a single way to implement this model that just works. You have to really think about the structure of your website in terms of it's pages, and figure out how you can represent that structure in your code. For one company I worked for, I used the page object model against pages that were very simple ...


4

My answers below are based on the framework that we've built, which uses a state machine to traverse the application we're testing. The URL (or, rather, a compiled regex representing the URL) is indeed a property of the individual page objects in my test suite. They all descend from a base page object very similar to terryp's (though we've converted to ...


4

After spending some more time with WebDriverWait, I came out with something nicer: Client code: /** Page Object. */ public class Page { private WebElement mySelect; public Page setMySelect(String optionText) { String optXpath = String.format("./option[text()='%s']", optionText); mySelect.click(); waitForOption(driver,...


4

There are times when using the Page Object Pattern makes a lot of sense and times where it doesn't make as much sense. If you have a web application where it is basically one single dynamic page then it makes less sense, however you can still use "page" objects that are really more like "section" objects for common pieces, for example if you have a Left Nav,...


4

I actually wrote that library while I was at a company creating automation for them. I had plans to open source it, but unfortunately never was able to and have since moved to a different company. In the presentation I was using the library I created, however you can build your own abstraction layer that does many of the things I talked about as well, or ...


4

It all depends what high level operations you have on your page. The requirement of High level functionalities differ from application to application and page to page. Some of the pages may not be having any or some of the options mentioned by you but some may have additional operations like Edit : Change the record to edit mode Delete : Delete the ...


3

Given that there is disagreement, the answers this question attracts will probably gravitate toward sometimes rather than yes/no. My opinion is that page objects should have assertions in their constructors, so that my code doesn't offer page methods for a page I never reached. In a made up example, I don't want to return an account page object when I've ...


3

I do not know which ''this'' you are referring to when you ask, "Am I getting all this wrong?" According to the Wiki page, the isLoaded method should use JUnit assertions to check whether the page is actually loaded. JUnit assertions throw Errors, not exceptions, to signal that something went wrong. LoadableComponent could have refactored isLoaded into ...


3

I had similar question few years back. At that point I had only seen page object based implementation. In my current company we have a single framework that manages mobile, web, web services. A nice presentation of page object challenges is available in http://www.slideshare.net/abagmar/perils-of-pageobject-pattern. There is also a youtube session on the ...


3

We have had a very hard time automating the Google Maps API. Test case: Surf to Google maps: https://www.google.nl/maps Find an area with known location Click the known location (without the use of mouse-coordinates, should also work when zooming, etc...) Verify the location box with details opens Retrieve the phone number This is very hard, because ...


3

I recommend avoiding external documentation because no one wants to maintain it. Instead, use comments in your code and useful names for your classes and methods. And ask someone to review some of your code specifically with those considerations in mind.


3

I think that you should create a page object class for each page of the site. If you have a single page site, you can create page widgets instead of page objects. The page widgets will correspond to components of the web page (example: footer, header, etc). When the number of your page object classes increases, you should create a base class that all page ...


3

Generally architecture of System Tests should comprise Page Objects, Business Layer and Test Cases. The fact that your Page Object gets bigger with the number of the fields makes sense. It will happen. The complexity of Page Objects gets higher with the complexity of UI. All in all you need to keep a mapping to the page somewhere. Even if you find a way to ...


3

I would assert an expected element is present on the returned page using NUnit eg Assert.AreEqual(loginPage.LoginButton.ToString(), "Login"); Common elements to use would be; an ID (unique element on the page) Page Title Contextual (like the example above). Avoid using things like the URL which often contain things like session information (...


2

I use Python and Selenium 1 and find page objects very useful. Mostly don't care about the URL. I check the page contents to make sure I'm where I expect. Most of the fields in my page objects relate to form fields on the page. I also have object fields that can read bits of static text based on the DOM. I have a base class with a variety of utility ...


2

I write my Selenium tests in Clojure, a Lisp that runs on the JVM. While it is possible to define objects in Clojure, it makes more sense to organize Lisp code using functions rather than objects, so my tests are all written as functions with the occasional closure. (I mention Clojure to put into context why I don't use page objects, not as an endorsement ...


2

Given that you can't return a page object, you might have each test stuff its last page object into a member variable, so that the next test can access it. This is ugly, of course, because it increases the dependence between tests, and does so in a not-exactly-obvious way. But the results might give ideas about what to do next. And if it's too ugly you can ...


2

Your question hints at a couple of questions: What Is a Page Object? A page object is code written to model an actual page (or part of a page) in a web application. Eg. each page in your app, would have an associated page object file that provides the “services” that the actual page offers. Eg. if there’s a button on a page in your application, you would ...


2

Page Factory Pattern is like an extension to Page Object Model , but Page Factory is much enhanced model. To start with, we just need to import package org.openqa.selenium.support.PageFactory "Factory class can be used to make using Page Objects simpler and easier". We use Page Factory pattern to initialize web elements which are defined in Page Objects. ...


2

Your screenshot function is creating a new WebDriver instance each time and then taking a screenshot of the default blank page in firefox. You could try passing in your test's WebDriver instance so you get a picture from your test: static public void screenShotOnError(WebDriver driver) { long epoch = System.currentTimeMillis(); String ssTimestamp = ...


2

@FindBy(css="a[dta-qid='inventory']") I've used that kind of locators in my last project and it's worked like charm. I hope this is that You want :)


2

"Test automation" means more than just automating user interfaces that run in a web browser. Someone with good programming skills should be able to find many other ways to use software to test software. Here are are couple of examples: Write API-level integration tests. If developers test, they probably focus on unit tests. There is a middle ground ...


2

Strategy is automation. Could be: Brutal force: read all values on all pages to a field variable and compare each with it's neighbor. Simple task for test automation. Optimised: sequentional read of the parameter and compare with the previous and next value, regardless of independently switching to the next page, if you reach end of the list. Avoidance: ...


2

Page Objects are great in the right circumstances. They allow growth. Initially when you only have a few fields on one page, they are not of much use. Each field is probably fairly unique already and identifying them is trivial and short. As the application grows the following starts to happen: the same field is in multiple spots on the same page the ...



Only top voted, non community-wiki answers of a minimum length are eligible