When defining locators in the page object classes, a static name is always given to the WebElement or MobileElement. This name should be referenced in the methods in the class that act on the element. Methods can either directly call a Selenium API method on a static element, or take a WebElement or MobileElement as a parameter.

Using the Gmail login page again as an example, the email and password fields would look like this:

// use of static WebElement name in method
public void login(String email,
                  String password)
                  throws Exception {

    this.email.sendKeys(email); // static WebElement name
    this.password.sendKeys(password); // static WebElement name
    submit.click();
}

// use of static WebElement name passed in as method parameter
public void login(WebElement username,
                  String email,
                  String password)
                  throws Exception {

    username.sendKeys(email); // static WebElement name passed as 
                               //  parameter
    this.password.sendKeys(password); // static WebElement name
    submit.click();
}

Although the use of static names seems fairly straightforward and simple, it needs to be a standard that is followed throughout the framework. Many developers stray from this approach, using the dynamic WebElement FindBy API calls directly in the methods (which require a locator), and thus, creating much more framework maintenance than usual.

Why is that so? That is because the WebElement is not defined in one place and referenced many times. It is defined in many places, and referenced many times in various methods. If that locator changes, which they do all the time, then it needs to be fixed in many places. It makes sense to just define the WebElement locators upfront for all the static elements on the page.

However, that does not apply to testing dynamic objects in a table or on a page. For instance, take an application that creates user accounts. If a test requires 25 different user type accounts to be created and verified in a list, table, or simply on the page somewhere, it wouldn't make sense to define all those WebElements in a page object class. That is very inefficient and really impractical.

Users need to use techniques to derive locators on the fly for these dynamic types of testing. We will cover those techniques in the next couple of sections!