Page Object requirements and behavior


#1

Hello:
I am working on the next generation of our scripts and I have a couple of questions.

  1. Lets say I am performing a search for different keywords and ensuring that the correct results show up with a known database. Does the page file have to be unique to every single different result page we might get?
  2. Does the initial screen shot that is saved when the page file is created have to encompass all the possible objects that I might want to interact with in the future?
    Thanks!

#2

Hey there @micheleaz,

I fear I don’t really understand what you’re trying to do, could you lay out your scenario a bit more and perhaps explain what you’re referring to when saying Page file (is it a Page Object ?!)

What I understood so far is that you have a page with a text field allowing users to search for something. Hitting search will result in a new page showing various hits for the search term and now you’d like to compare that the list contains exactly a set of known items.


#3

Hi @vsoftic I am sorry for the cross of terms. When I say Page File-- I mean page object java file.

So essentially what I have is an web app with a front end that queries a back end database and displays info built with keyword searches. We have a prebuilt database on the backend that has known data. So what we want to be able to do is during an automation run, be able to type a keyword search in such as the word “bike”. When bike is searched for, a list pops up with terms that relate to bike. We want to be able to check the number of results that show up as well as manipulating the results during a run. We will do a database overlay at the end of the automation run to restore the database to a known good state.So in this instance, lets say we search for bike and do some stuff and then in a separate search, search for car and then do some other stuff. Can bike and car results share a page object file? Or do I have to have a separate page object file for every search result that we want to do?

As far as the second question, lets say I take an initial screen shot of a page to create my page object file. It has 3 buttons at the top of the form and 4 buttons at the bottom. Does my initial screen shot have to encompassed all 7 buttons?


#4

Aahh ok, so you’re essentially talking about a dynamic result page which might have different appearances based on the search term.

So in general I’d, without knowing more details, would say you’re good with one Page Object. Whether there are 3 or 4 buttons is merely a state of your PO. Unless that is that each state has utterly different behavior. In that case I’d think they are no longer representing the same component.
E.g imagine you’d have a toggle button. If its active its State A, if its inactive its State B, but still the button is part of the same PO and does pretty much the same thing -> Switch from one to another state.

Now as far as it goes for the Screenshot, Selocity can only capture the visible part, thus your generated PageObject screenshot will most likely only show 3 or 4 buttons, except you have a condition that shows all 7 of them. The screenshot though is just a reminder for the user (what part of the page am I working with) and has no other immediate effect.

Moreover whats interesting though, you’d most likely have elements in your PO defined for those individual buttons. In that case I’d propose to add selectors for all the 7 there.

A very important thing, that can’t be stressed too often, is that the term Page Object is a bit misleading as it comes from a time where UIs have been pretty simple, so a PO per Page was sufficient. Nowadays you should try to think more about a Component Object. Speaking a part of the page (or perhaps even reused in multiple places) is your Po. That might also reduce the overhead of your ResultPo.
So if you feel like the complexity of your ResultPo starts to grow (too many states encompassed), perhaps try to break it down even further. E.g the list of results could be a ResultsListPo, whereas the mentioned buttons could be put into a ResultsActionsPo.

As a software developer a good practice is to follow the YAGNI model which essentially tells you to stop doing too many abstractions right away since … well you ain’t gonna need it most likely :slight_smile:
Another important practice though is continuous refactoring. That means feeling brave enough to change existing code in order to reshape it for better re-usage. I think both of those could very well apply to your situation. Start small with a single Po for the results. If things get tiresome, start to slowly refactor into smaller POs, and if things go south due to vastly different state effects, introduce individual POs per state.