Amir Ghahrai Amir Ghahrai - 1 month ago 8
Java Question

Page Object Model Best Practices in Selenium

When you are modelling your page objects, how would you deal with a page which has form and about 50 input fields on it? What is the best practice here?

Would you create a page object and write a separate function for each input action? or would you write one function which parameters are passed to it and enters the text?


public void enterFirstName(String firstName) {
driver.type("firstNameField", firstName);

public void enterSecondName(String secondName) {
driver.type("secondNameField", secondName);


public void fillInForm(String inputFieldName, String text) {
driver.type(inputFieldName, text);

I can see in the first model, when writing tests, the tests are more descriptive, but if the page contains too many input fields, creating the page object becomes cumbersome.

This post is also quite interesting in structuring selenium tests in Page Objects
Functional Automated Testing Best Practices with Selenium WebDriver


I always like to break things up into groups of related information. For instance, if I have a user class I might break that up into a few smaller classes: LoginCredentials, ProfileInfo, Settings, etc, but I would still usually have a top level User class that contains these sub classes.

One thing I would certainly recommend would be to pass in an object to one FillForm function rather than all of those individual functions. There are some great advantages using this approach. One, you could have some "common" pre-configured objects that you use for many of your test cases. For instance:

public class FormInfo
   string Domain;
   string Name;
   string Category;
   // etc...

  public FormInfo(string domain, string name, string category)
     Domain = domain;
     Name = name;
     Category = category;
     // etc...

// Somewhere in your initialization code
public static FormInfo Info1 = new FormInfo("myDomain1", "myName1", "myCategory1");
public static FormInfo Info2 = new FormInfo("myDomain2", "myName2", "myCategory2");

You can still update one of your common merchants if you need to do something one-off:

// In your test case:
Info1.Category = "blah";

OR, you can create a brand new merchant object for a specific test case if necessary. You can also do things like field validation either using these objects, or what I normally do is break the page object pattern for specific field validation, so if I am validating the merchant domain field I might do this:

Info1.Domain = null; //This should make the FillForm function skip doing anything with this field.
FormPage.DomainTextBox.Text = "field validation string";

Another important advantage of this approach is that if the page is ever updated to add, remove or modify fields, you would only need to update your FormInfo object and FillForm function, and would not need to modify specific test cases that call the FillForm function - assuming they are using one of your common FormInfo objects. Another possibility to get more coverage would be to set up one of your common FormInfo objects to generate random strings for each of the fields that comply to the min/max length and cycle between all different allowed characters. This allows you to get some additional testing out of the same set of tests, although it could also add some noise if you start getting failure results only from specific strings, so be careful.