Given that your are using Java I would go with page object methods.
For the way they are used, either approach will work.
For example I have converted tests and in one form I was using variables:
storedVars["css_phone"] = "css=input[name='auto_policy[phone]']";
storedVars["css_email"] = "css=input[name='auto_policy[email]']";
storedVars["css_street"] = "css=input[name='auto_policy[street]']";
and in the other approach these became (ruby) page object methods:
but their use was essentially the same.
The important thing to focus on was creating good unique selectors that would not be brittle.
Page Objects are great in the right circumstances. They allow growth.
Initially when you only have a few fields on one page, they are not of much use. Each field is probably fairly unique already and identifying them is trivial and short.
As the application grows the following starts to happen:
- the same field is in multiple spots on the same page
- the same field or collection of fields are on different pages, e.g. many 'help' or 'login' buttons.
- the number of fields grows and different approaches by developers leads to style clashes.
- the correct way to identify elements become a longer string of finders cluttering up the test
- names of fields and containers change over time, sometimes consistently, other times not
- more business logic is added.
In these circumstances having the selector finders embedded in the test code leads to brittle, duplicate, error-prone, hard to maintain code.
Centralizing them in one place addresses these issues and helps:
- reduce duplication
- clarify readability of actual tests
- separate business logic from selector identification
- help reduce change and churn due to layout and styling changes
- encourages the same approach as all the selectors are in one spot
For example if selectors appear on multiple pages, page objects will help guide you to one identifier, such as id, that will be usable. You'll be forced to think about good naming and name spacing up front.