Suggested max size for Page Object file


#1

I am curious what the suggested max size for a page object file should be? I have a page object file that has grown to 1430 lines, there are a ton of fields and methods for this particular function in our application. I am seeing the editor start to have major slowdowns and will stop totally for several seconds and then catch up on what I typed which is quite distracting. I can obviously break this page object file into several smaller files but I was curious if there is anything from a settings standpoint that could improve performance in the editor?

One other quick item…it would be great if the editor sorted the web elements in alphabetical order so you could easily find an element when you want to create methods on that element.


#2

Hey @jmsc7ran,

first, thanks for the feedback with sorting the elements. I’ll add this to the backlog, definitely a nice idea. Perhaps even with sorting in place so one could change the order ASC/DESC.

Now with regards to your PO file size I’d say … it depends :slight_smile:
The less the better, as usual since you have a much easier time to grok what a specific PO is about.
Without knowing any details, would you be able to share a screenshot of the overall PO you’re about to tackle? If your own one is private, perhaps you can find a public website that has similar aspects and share a section you’d like to have treated as a PO as alternative.


#3

Thank you for the feedback!
I’ve decided that I need to break my Reports PO file into smaller sub function files. Sadly, our app is written in JSF with Prime Faces and the reporting options are exhaustive plus there is duplication across functions that make the PO file a nightmare. It’s a case of trying to cover every possible report flow in our application and then give the user 12 different ways to get at the same data. A nightmare for automation.

On a positive note we are re-working our UI and moving to React so my automation life should get better soon!


#4

ouch, wish you all the best with it, you’re going to need it :slight_smile:

Private preferences aside, thanks for explaining your use case. So reporting is exactly one of these complicated scenarios where seemingly everything belongs to the same PO.

Imagine the following scenario as shown by the picture below

  • ReportPO would be the initial entry PO to handle housing all components + overview
    • getTotalRevenue() (total revenue row)
    • viewReport(driver) (view button)
    • getFilter(driver) (returns instance of ReportFilterPO)
    • getPagination(driver, position: “top” | “bottom”) (returns instance of ReportPaginationPO with indicator for top or low)
    • getGrid(driver) (returns instance of ReportGridPO)

So the ReportPO merely controls the submit button and the total revenue while providing getters for the other POs

Now all the individual logic for pagination, filtering and the grids behaviors can be done in their respective sub-POs. A sample test at the end might look like:

ReportPO sut = new ReportPO();
sut.getFilter(driver).filterBy("Alphonse"); // assuming that filling out the field will immediately refresh the page
// imagine we end up with 2 pages
sut.getPagination(driver).selectPage(2); // or 1, depending how you calculate the index
String filteredRevenue = sut.getGrid(driver)
  .orderBy("Customer ID", "DESC")
  .textOf(4, 2) // row, column

Assert.assertEquals(filteredRevenue, "303,244.00");
Assert.assertEquals(sut.getTotalRevenue(), "1,303,244.00");

Of course this is a super contrived example but I hope it gives you the idea how you can create an overarching PO, which controls/instantiates sub-POs to maintain a separation of concerns.

Now while that might be the first part, nothing prohibits to go even further in where the ReportGridPO could again be split up in parts for the ColumnFilter, Ordering and RowSelection. It’s all up to how granular and modular you need things.