How do I split my PageObject Model classes?

Question

My page object model class is getting rather long.

Should I create a different class with the same name as the page object model with a 2 added at the end. Or does this go against the page object model?

Answer 1

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.java when trying to find a submit button?

Note that Martin Fowler, one of the popularisers of the PageObject pattern, states that Page Objects do not need to be full webpages. They simply just link together related elements:

"There's an argument here that the name "page object" is misleading because it makes you think you should have just one page object per page. Something like "panel object" would be better - but the term "page object" is what's become accepted. Another illustration of why naming is one of the TwoHardThings."

So, you can break down your pageObject into discrete, reusable chunks.

For example, on a project I worked on, we had a similar widget for search-as-you-type that was used on a number of pages. There were a number of different elements to interact with and methods that could be used against this single small part of the page (enter search, select first answer, count number of answers.. etc). This search element appeared on quite a few pages. Instead of repeating the exact same code on different pages, we created a separate class for this object and included that as a public object on every PageObject it appeared on. Calling a search on a page was as easy as doing:

myDashboardPage.searchWidget.enterSearch("search text");
myUserPage.searchWidget.selectFirstAnswer();

With no duplication of code on the pageObjects, and a logical hierarchy of pages -> widget -> html elements.

Answer 2

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 object classes will inherit from.

This will give you 3 layers:

1. test scripts: use the page objects
2. page objects: use the base class for interacting with the site
3. base class

See on this article a sample project about how to create page objects: http://test-able.blogspot.com/2015/09/how-to-write-better-automation-code-with-TDD.html

Alex