The Page Object Pattern is a strong and efficient way to create, maintain and reuse test scripts for testing Web applications. PageObjects bring object oriented programming to test scripts. Selenium PageObject is a software and test development pattern to represent Web pages or parts of Web pages. PageObject is an approach to building test scripts that break when the application changes. For Test Case developers and testers, PageObjects brings a component approach to organize test code and avoid having to always focus on the implementation details. 

Adam Goucher, maintainer of Selenium IDE, and Frank Cohen of PushToTest, discuss PageObjects in a screencast.

http://www.pushtotest.com/selenium-page-objects.html

-Frank

Great.  Now all selenium needs is a QA department, since they obviously don't have one of those.  Also, Geb already does page objects very nicely.  

I had not heard about GEB before. "Very Groovy browser automation… web testing, screen scraping and more". The Book of GEB is a thorough reference guide for GEB at http://www.gebish.org/manual/current/

I didn't see anything in the Book on how to data-enable GEB tests. Other than writing DOA objects in Groovy is there anything else?

-Frank

thats what i though too Frank...i did not now any of it

stork club new york

Please explain that part of your comment?

I agree that selenium is a great tool and it is great to prescribe a process of applying it in a structured way.

However, PageObjects are nothing new. They are just a specialization of the "Chain of Responsibility" pattern (CoR). The "command" is the test context, global variables that survive throughout the use case, and the "processing components" are now renamed as "PageObjects".

Even as a specialization of the "CoR", PageObjects dont make much sense. What is the guideline? They are "pages" or "part of pages" ???? It would make more sense to describe them as "reusable parts of a use case" and get rid of the page scope all together.

I strongly disagree with the coining of a new term for a pattern that already exists. I really prefer to call it CoR. In this way I can just reuse the concept when I am testing components and not web pages.

Factoring a PageObject on the page or an object in the page is a matter of re-factoring the test code routinely. Adam describes it in the screencast as an ongoing process. Start with the entire page and then break it down into parts of the page over time.

IMHO (I'm not the PageObjects guy) the Selenium project is caught between the world of proprietary test tool vendors and the software developer community. The proprietary test tool vendors (HP, IBM, SmartBears, MicroTrend, CA, etc.) tell testers not to learn how to code. Don't worry, they promise, we will take care of the complexity and give you a simple record/playback tool. The software developer community urges austerity to build reusable, easily maintained, pattern-based test objects.

Just as IDEs include Wizards to create new applications and classes, testers have tools that make it easy to start with record/playback and move into coding. There is a tipping point in tester productivity between record/playback and coding. My open source test tool, TestMaker, delays the tipping point a little by providing the TestMaker Object Designer (http://www.pushtotest.com/designer) for record/playback and then also runs test objects written in Java, Ruby, Python, and others once those make sense.

The problem for testers-that-want-to-code happens when they tip into object oriented coding patterns. Selenium does not have a official person or company to designate best practices. Oracle/Sun used to have this role for Java. It espoused EJB as the structure and patterns. HP and IBM have abdicated their responsibility to provide a code, community, and patterns around testing. That's a shame for testers who want to code.

The average tester that wants to code test objects has a variety of competing approaches: Selenium PageObjects, GEB, FIT, Fitness, etc. No wonder it is a confusing world for testers.

-Frank