Explore Courses Blog Tutorials Interview Questions
0 votes
in DevOps and Agile by (19.7k points)

When you are modeling 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

1 Answer

0 votes
by (62.9k points)

I continually wish to break things up into groups of related data.

For instance, if I even have a user class I'd break that up into some smaller classes: LoginCredentials, ProfileInfo, Settings, etc, however, I might still typically have a

top-level User class that contains these subclasses.

One factor I might definitely suggest would be to pass in an object to at least one FillForm function instead of all of these individual functions.

There are some great advantages to 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 produce a fresh merchant object for a selected test suit if necessary.

You can additionally 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 would 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 chance to induce additional coverage would be to line up one of your common FormInfo objects to get random strings for each of the fields that fit

the min/max length and cycle between all completely different allowed characters.

This allows you to induce some extra testing out of a similar set of tests, though it may additionally add some noise if you begin getting failure results only

from specific strings, so be careful.

Browse Categories