Advantages/Disadvantages of separating elements from behavior vs keep together in page object class

[carina0110]

(Using Eclipse/Webdriver/Java/TestNG)

I'm trying to decide on the best way to set up a selenium 2 framework and I find two approaches of interest to me but I'm not sure on the pros and cons.

APPROACH 1
This one is taught in selenium classes all over. You create a page_elements class to store all elements and a page_object class for the behavior of elements in a page.

APPROACH 2
This one uses a page_object class to store all the elements and methods for the page. Verifications are done at the test level script.

Could someone explain to me the pros and cons of each? (Let me know if you need more info)

[David]

I'm interested in this discussion. I didn't know approach 1 "is taught in selenium classes all over the world". Haven't noticed it here in the US at least, though I haven't attended any such classes as I haven't had a need to.

[carina0110]

I'm probably not wording it correctly. It's here in the US I'm referring to. Here's how they're doing it: A page object class is created to store the methods applicable to a specific application page and a page elements class is created with the elements for that same page such that the elements are in one class and the behavior in another class for the same page.

 

The class containing the page elements also contains a get method for each element defined in the file which return a By value. Ex:

   public class PageElements {   

       ...

       public static String buttonElementXpath = [xpath goes here];

       ...

 

       public static By getButtonElement() {

            return By.xpath(buttonElementXpath);

       }

   }

 

Supposedly this is good when the element description is dynamic among other things.  I forgot the explanation I was given regarding the pros of this approach.

 

I was using the other approach where both the elements and methods pertinent to that page are stored in one page object class. In this class, I use the @FindBy annotation to declare the elements and add whatever methods I need in to work with those elements, all in one page object class.

 

If you can explain the difference between the two, I would appreciate it.

 

thanks

[David]

May I ask which class(es) are teaching that approach. Just out of curiosity. Because in online discussions, like here, I hear most people advocate the second approach of everything in page object as the norm.

Excluding discussing dynamic elements, it comes down more to preference on which design is easier to manage and maintain for you. Personally, if I was going with first approach with separate page elements, I may consider changing it further to store the locator values in a Java properties file, etc. and the page element class can then instantiate elements by reading in the property file info and return a By object. Or abstract/simplify the page element class such that it's more of a utility method to dynamically return By object for given locator specified in properties file than to have several layers of abstraction (page object, page element, properties file with locator). I like the idea of locators in properties file as you can make changes w/o having to modify the source code. Similar to application config files to specify settings & startup options.

[carina0110]

Preferred Approach

----------------------------

Thanks, David. I still prefer keeping both elements and methods for a page in one class. A large application can have many pages and, unless, there's a clear advantage, I just see clutter. I'll have twice as many files to look at.

 

Now, the thought of putting code-level data in a properties file (i.e. it's not configuration data) is bothering me but I can't articulate my issue. I think that 8 out of 10 times I will still need to change some code somewhere related to those locator changes and, so, I don't think it will save me much. I'll end up with tons of properties files; now some for configuration data, and many for page elements. Then, I may have to deal with merging some of them and making sure that there are no duplicate keys in the merged file. And I wonder if I'll have to add thread-related considerations. (Not a guru over here)

 

Still, I'm going to try the approach of turning the elements file into a utility method and load locators from properties files and see if it grows on me.

 

Schools

------------

As for what schools are teaching this...well, maybe I overdramatized things a little. But I saw class videos in youtube and, in there, the instructor opened briefly this large file with rows and rows of locators. That was, in essence, an object repository to mimic what's done is many commercial tools. Then, in the company I just joined, I saw a similar setup but this time not one repository for all but each page has its elements page. I talked to one of the engineers that was sent to training and she said (she does QTP) that she is not sure they were taught that approach precisely. She thinks they (the engineers at my company) may have thought of it themselves. Since Selenium is new here and their background is QTP, they may have tried to mimic QTP standards.

 

Thanks so much.

[Ross Patterson]

The best part about using properties files, or XML files, or JSON files, or ... is that non-programmers can adjust tests to changing circumstances (e.g., simple text changes in the app, relocation of elements).  The worst part is that the programmers who are the only ones who can understand the test logic don’t have immediate access to the details that bind the app to the test (e.g., locators, important text).  Even worse are the anti-patterns that result in the same element details existing in multiple properties/XML/whatever files – as an old colleague used to say, “data in two places is wrong in at least one”.

 

As to schools, it’s the fallacy of approaching test automation from the automated-manual-test world.  Systems like QTP and its ilk love their “object repositories”, which are just gussied-up spreadsheets, and trainers with manual-QA and QTP-automated backgrounds see those spreadsheets as good ideas.  But if you start from a programming background, you never wind up there.  Those repositories/spreadsheets are what another old colleague used to call “Worst Practices”.

 

Ross

[Ross Patterson]

There was a really good concrete discussion of implanting the PageObject pattern back in June 2011: https://groups.google.com/forum/?fromgroups=#!topic/selenium-users/QYEC5-clH_k  It has a number of real-world examples from folks who have actually done this stuff.  You might find it useful.

 

Ross

 

From: seleniu...@googlegroups.com [mailto:seleniu...@googlegroups.com] On Behalf Of carina0110
Sent: Thursday, November 01, 2012 5:24 PM
To: seleniu...@googlegroups.com
Subject: [selenium-users] Re: Advantages/Disadvantages of separating elements from behavior vs keep together in page object class

 

I'm probably not wording it correctly. It's here in the US I'm referring to. Here's how they're doing it: A page object class is created to store the methods applicable to a specific application page and a page elements class is created with the elements for that same page such that the elements are in one class and the behavior in another class for the same page.

[Ross Patterson]

This sounds like an anti-pattern to me.  Object-oriented programming, of which the PageObject pattern is a variation, usually leads you to combine both data and related operations into a single class, and often to hide a lot of the data from other classes as a result.

 

“Dynamic” elements are a red herring.  What most people mean when they call an element “dynamic” is that it is created at run-time by some piece of code and doesn’t have certain predictable characteristics that make it easy to identify.  I’d say every element described as “dynamic” merely have an unpredictable ID= attribute, and have plenty of other predictable characteristics that can be used to locate them.  In fact, if they don’t, you’re not going to be able to automate them at all, because you can’t tell a program how to find them.  You can handle these “dynamic” elements just fine with any style of coding, whether it’s split-data-and-method, straight-line-test-code, external-spreadsheet-of-locators, or something else entirely.

 

Ross

 

From: seleniu...@googlegroups.com [mailto:seleniu...@googlegroups.com] On Behalf Of carina0110
Sent: Thursday, November 01, 2012 5:24 PM
To: seleniu...@googlegroups.com
Subject: [selenium-users] Re: Advantages/Disadvantages of separating elements from behavior vs keep together in page object class

 

I'm probably not wording it correctly. It's here in the US I'm referring to. Here's how they're doing it: A page object class is created to store the methods applicable to a specific application page and a page elements class is created with the elements for that same page such that the elements are in one class and the behavior in another class for the same page.

[carina0110]

thank you so much Ross for taking the time to go at length on this topic. This is very valuable information for me.