I am new to Page-Object model automation using selenium and java. I am using the Page Object model and have each page as a single class and the actions in that page as methods. Should we write separate page-object for a simple pop-up which appears when submitting a form. This pop up is used to select service types and based on the selection correct form will be opened next. I have 'page objects' for the pages before and after this pop up. But for this one I just inserted a direct code to select an option and click next button. Should I create a separate page-object class for this pop-up?(as this is not a Page). Pop-up has 3 options and a Next button to proceed.
4 Answers
I agree with Bill, however I handle my popups a bit differently. I have it as it's own page object within the same class if it is a page specific popup.
For instance, if you have a popup on your dashboard page that is page specific to the dashboard page but not found anywhere else in the web application, I make it it's own class within the dashboard page object.
The reason I do this is I find the tests far more readable when the specific areas of the application are "containerized" within their own objects. Then when you open the popup and do operations on it, they would look like "popup.SetValue" versus "dashboard.SetValue" or something similar to that. Doing it this way you know that you are doing operations on the popup versus testing the dashboard.
If the popups are widespread throughout your application and can be reused easiliy I would suggest making it into it's own Page Object.
Please read this Martin Follower's article - Page Object.
A quotation:
Despite the term "page" object, these objects shouldn't usually be built for each page, but rather for the significant elements on a page
Imagine a page which has over of dozen tabs, panels etc, and each one have a few fields, buttons etc. It would be impractical to create a huge class for such a page, it would certainly have 300-500 or more lines of code. Such a class would be very hard to maintain.
It's better (in my opinion) to create several small classes (page objects), each for a specific section of the page, each one containing only a few elements, each no more than 50-100 lines of code. We call these classes page fragments instead of page objects, but the concept is the same.
But it will vary from person to person and everyone may have a different opinion on this topic.
There's not really a hard and fast rule. As others have stated, the page object doesn't have to be a page. It really should be any piece of reusable functionality such as a dialog or header or footer, etc. For automation that I have written, I decided to follow the rule that any dialog is a separate page object (actual separate file). I find that it helps me keep track of pages/dialogs, etc.
To further help with this, I name my classes *Page for pages (e.g. LoginPage.cs), *Dialog for dialogs (e.g. AddImageDialog.cs), *Panel for panels (e.g. HeaderPanel.cs), and so on.
If a dialog only exists on a particular page, I named it based on the base page name, e.g. ProductDetailsPage_AddImageDialog.cs. What that does is when I look at the list of files, they will sort in alphabetical order so all the page objects related to the product details page will sort together so I can quickly see how many page objects are associated with that page and what they are. Some examples are below. You can look through the list and quickly determine which page objects are associated with a particular page and which ones aren't.
HeaderPanel.cs
LoginDialog.cs
ProductDetailsPage.cs
ProductDetailsPage_AddImageDialog.cs
ProductDetailsPage_AddTextDialog.cs
ProductDetailsPage_SaveCompleteDialog.cs
ProductDetailsPage_SaveYourProjectDialog.cs
If a dialog occurs multiple times throughout the site (not associated with a single page), I name it as a standalone page object, e.g. LoginDialog.
I used to just name the page object after the dialog, panel, etc. but after you get 50 page objects, it's hard to remember where certain dialogs occur so I came up with the _ naming scheme and it has helped significantly.
I also considered creating the AddImageDialog page class inside of the ProductDetailsPage page class but when you get larger pages with lots of dialogs, it just makes the file bigger and bigger. I prefer to keep the file size as small as is reasonably possible while keeping all the important bits in there. Breaking the files down into pages and dialogs and having them separate maintains the page object model principles while keeping things cleaner... at least in my opinion.
If the pop-up has an ID locator, and is likely to happen on other web pages, I would put it in its own page object, but often the pop-up is tied directly to the current page and would therefore be better included in that page's object definition.
The only reason I would consider putting it in a separate page object is if it did get used in other pages AND used the same ID locator, as if and when that locator changed, you'd only have to edit the one page object instead of locating and fixing all other page objects that also refer to that pop-up.
Related