Automating form dealing with large number of element

Question

This is more of test design question than pure Selenium question. I have a form in my application and while following page object pattern I wrote a method which has many parameters -

newMerchantPage.addEditMerchant(merchantDomain, merchantName,
        merchantCategory, true, merchantDescription, merchantNotes,
        merchantTags, true, true, false, false, merchantTitle,
        additionalDescription, merchantHeading, dummyCouponLink, true);

Method looks horrible, and then I was suggested to break it down in multiple small method in page object class i.e

typeMerchantDomain(String merchantDomain) {
//
}

typeMerchantName(String merchantName) {
//
}

and then call them instead of my heavy weight method. There is one more advantage of this approach that if I can easily do data validation only individual field.

Is it the way to go about it? I feel my code would yet be crowded as I would have to make many more method calls than just one "heavy" method call I am doing right now. Any suggestions?

n.b. I posted this question on java forum, but this should be better place to get test automation design related answers.

UPDATED CODE -

After many suggestions (using "this" set methods and passing object to method), I made modification and another method of mine looks as -

ContactPage contactPage = new ContactPage(driver);      
setContactFormData()
contactPage.setName(name).setEmailAddress(emailAddress).SOME MORE SETTERS;
contactPage.submitContactForm(contactPage);

Here my page object - contactPage is used to call the method and the same object is passed to method to determine what data is to be passed on to web page fields eventually.

Is this implementation of calling method on object and passing same object as argument ugly? Should I be creating a "PageDate" sort of class having ContactData class so that I could do -

contactPage.submitContactForm(contactDataObject);

Answer 1

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 a merchant object rather than all of those individual variables into your addEditMerchant method. There are some great advantages using this approach. One, you could have some "common" pre-configured merchant objects that you use for many of your test cases. For instance:
public class MerchantInfo
{
string MerchantDomain;
string MerchantName;
string MerchantCategory;
// etc...

public MerchantInfo(string merchantDomain, string merchantName, string merchantCategory)
{
MerchantDomain = merchantDomain;
MerchantName = merchantName;
MerchantCategory = merchantCategory;
// etc...
}
}

// Somewhere in your initialization code
public static MerchantInfo Merchant1 = new MerchantInfo("myMerchantDomain1", "myMerchantName1", "myMerchantCategory1");
public static MerchantInfo Merchant2 = new MerchantInfo("myMerchantDomain2", "myMerchantName2", "myMerchantCategory2");

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

// In your test case:
Merchant1.myMerchantCategory = "blah";
newMerchantPage.addEditMerchant(Merchant1);

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:

Merchant1.MerchantDomain = null; //This should make the addEditMerchant function skip doing anything with this field.
newMerchantPage.addEditMerchant(Merchant1);
newMerchantPage.MerchantDomainTextBox.Text = "field validation string";

Hope this helps! Edit: I just realized I forgot another important advantage of this approach. This makes it so that if the new merchant page is ever updated to add, remove or modify fields, you would only need to update your MerchantInfo object and addEditMerchant function, and would not need to modify specific test cases that call the addEditMerchant function - assuming they are using one of your common MerchantInfo objects. Another possibility to get more coverage would be to set up one of your common merchant 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.