CODEWITHSUNDEEP
javaselenium-webdriver
Reez0
Reez0

Reputation: 2687

When using the page object model, is it absolutely necessary to create a class for each page?

For example, if I have a payments page that contains 2 buttons: Pay someone new and pay existing beneficiary. Do I create a class which performs relevant actions on those buttons, and then another class for once I'm inside pay someone new and pay existing beneficiary?

Is this how the payments page should look?

public class Payments {
    public void clickPaySomeoneNew(){}
    public void clickPayExistingBeneficiary(){}
}

And how the Pay someone new page should look?

public class PaySomeoneNew {
    public void setAccountNumber(accountNumber) {}
    public void setAmountToPay(amountToPay) {}
    public void clickPayButton() {}
    public void makePayment(String accountNumber, String amountToPay) {
        this.setAccountNumber(accountNumber);
        this.setAmountToPay(amountToPay);
        this.clickPayButton();
    }
}

Upvotes: 0

Views: 438

Answers (1)

JeffC
JeffC

Reputation: 25714

The short answer is Yes, you do need to create a class for (at least) each page. There are times when you should create a class for something that is less than a page, let's call that a Component. Examples of Components might be a header or a footer or a calendar widget that can show up on any page or multiple pages. These would each be their own class (page object).

In the specific case you are asking about here, it's unclear how it would be structured because you haven't stated whether PaySomeoneNew is a new page or just a part of the Payments page. I typically look at the URL. If the payments page is payments.jsp and the PaySomeoneNew page is paysomeonenew.jsp then I would create separate classes (page objects) for them. If they aren't separate pages then the answer is less clear. I have written page objects for a single page that essentially contain a wizard. You fill in form 1, click Next, and form 2 shows up but the URL hasn't changed. At that point it's a toss up. I think arguments can be made for keeping them together and separating them and both are (somewhat) equally valid. In those cases I tend to try to keep them in the same page but if the different panels are complex or large (or both), I would separate them.

Post webapp comment:

I would still break it down into logical segments. You could do it based on what you can see and call that a page. You could also treat each accordion's contents as a page. If there isn't much content in each accordion, I would just leave them as part of the larger page's page object. Just make up some rules (e.g. accordion content is a separate page object) and stick to them. If you don't like the rules after you've written a few page objects, adjust the rules and refactor.

For example, if all the accordions have 2 fields in them, it's probably not worth making each one a separate page so you would then refactor and add the accordion content back into the bigger page object.

Or you could go the opposite way, the rule is that the accordion content stays inside the bigger page object. Then you find that a bunch of accordions are hiding 50 fields so you decide that you want to break them out into separate page objects.

There's really not a hard and fast rule here. Do make some rules that you intend to follow so that it will make sense to the next person (or yourself in a few months). Follow those rules until you decide they no longer work. Write new rules and refactor.

Upvotes: 2

Related Questions