ouch, wish you all the best with it, you’re going to need it
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)
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
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.