3

I've got a question about dealing with huge PageObject. In the website that I'm currently testing there is a form with circa 50 inputs/dropdowns/selects.

In the current state my class got about 900 lines. It will be hard to debug, and in my opinion it's not so readable.

Is it consistent with the assumption of Page object model to create some subclasses and separate some WebElements and methods that are used by those elements? I'm using PageFactory so for declare all of the elements(I wrote circa 400 lines). It's so many.

3

Sure It’s pretty common to divide big page objects into smaller ones. There are also things like LoadableComponents. A lot depends on how this big form is shown.

3

I wouldn't recommend to over-structure your model. If some part of your form can be logically segregated (for example you have several use-cases of how one uses the form and some of them provide basic field set and some provide extended field set) than it makes sens to address this using class hierarchy. In other cases I would say that having 100 fields in 20 classes doesn't really simplify the things a lot against when you have 100 fields in one class.

1

If a web page has a header and a footer that is on other web pages, obviously it's a good idea to give them both their own page object definition.

It's also a good idea to limit your page object definition only to the elements that you want to test. Elements that you decide in later/other tests that are missing can always be added later without affecting tests that are already written using the existing definitions.

Use method wrappers to avoid redundant error-trapping and logging code. For example, have your page objects extend or include a general utilities type class that contains methods that wrap the common things such as click, sendKeys, exists, etc. and pass them the webelement and possibly a text description (for logging) as parameters. This way you can cut-down on the code in the page object and refine your wrapper logic to make it robust and consistent.

Guides that I've seen do indeed recommend as a "best practice" to keep the page object minimal in size, but sometimes it's unavoidable. The key, to me, it to keep it maintainable and understandable.

Hope this helps.

  • If all page objects should have non-trivial header and footer objects/components, then how should we inject the the components in the pages ? Should we make all the pages extend some base page object which has the header and footer ? Or should we use some dependency injection framework to inject header and footer into each page object ? – MasterJoe2 May 8 '19 at 5:21
  • 1
    I recommend keeping it simple and declaring heard and footer page objects separate from the page body for consistency. Any reference to a header element should only come through the header page object, for example. This might mean three page objects declared instead of one, but if we're talking about a lot of pages that most have headers and footers that need testing, it's better in my opinion to keep them separate. I would not place header or footer info in a base class unless every page had those elements. – Bill Hileman May 8 '19 at 11:48
0

Yes, it is absolutely ok. The approach that you are trying to describe is called Page Elements/Components, and basically is just an evolution of Page Object in terms of extracting other abstractions from the page (these might be dialogs, tabs, forms, etc, up to the low-level description of HTML elements).

Think of it as a composition in terms of OOP.

Since your code is written in Java, following OOP/OOD approach is needed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.