在这种情况下如何返回WebElement

Question

I wanted to utilize page objects and following is what i am looking at:

I have created a package 'pageObjects' and created a class 'HomePage' with element like below:

public class HomePage 
{
    private static WebElement element=null;

    public static WebElement txt_UserName(WebDriver driver)
    {
        element=driver.findElement(By.name("userName"));
        return element;
    }
}

Here in my Test Case, when i use HomePage.txt_UserName(driver).sendKeys("uday") lets enter the username as "Uday". This works perfect.

But what i need to implement above in a method like enterValue("HomePage.txt_UserName","Uday")

public void enterValue(String strObjID,String strValue)
{
  //How should i use the above parameter here?? Something like below should work
  strObjID(driver).sendKeys(strValue);

}

Answer 1

Based on your comment I think you should not write a generic cucumber step definition which handle all types of input fields. This makes it very hard to read and understand your feature files. Writing HTML ID or CSS selector into your HTML does not fulfil BDD because you write requirements at first and because of this you can not know which IDs you are using. Look at the principles of BDD .

Remember, that the purpose of a feature file is to link a requirement, written as user story, to your test code. So write your feature files like your user stories. For example:

Given I loaded the home page
When I enter my username <username>
And I enter my password <password>
And I press the login in button
Then I should be redirected to <some url>

Based on that, you should implement the page object pattern thoroughly. Here is an example:

public class HomePage {
    private final WebElement usernameElement;
    // declare more page elements here

    public HomePage(WebDriver driver) {
        usernameElement = driver.findElement(By.name("userName"));
        // init more page elements here
    }

    public void enterUsername(String username) {
        usernameElement.sendKeys(username)
    }

    // more handler here: e.g. public void enterPassword(String password) ...
}

In your cucumber step definition you can then use the page object:

@Then("^I enter my username \"(.+)\"$")
public void I_enter_my_username(String username) {
    homepage.enterUsername(username);
}

This pattern allows a good understanding of your feature files and how they are connected to your test code.

Answer 2

Please don't make a generic function. If your form has 50 elements, you will have to deal with all 50 at some point anyway. The better practice is to put all the code in the page object rather than the test case script. You should not require a consumer (script writer) to have knowledge of the HTML of the page. They should be able to call a simple function like login(username, password) ... not enterValue("some crazy XPath", "my name") and enterValue("some other crazy XPath", "my password") . People that come along later are not going to be able to tell what each line does which will make debugging much harder and more time consuming.

I agree with Schrieveslaach but I would take a slightly different approach. I would say that you should bundle the elements into actions that a user would perform on the page. For example, instead of enterUsername() and enterPassword() and clickLogin() , use login(username, password) that fills in the username and password and clicks the login button. That will simplify the API of your page object and only expose necessary actions. Who is going to fill in a username but not a password? There will be times where you will want to fill in some fields but not others, maybe for negative testing, in those cases you can pass in empty string for some fields and accomplish this.

Answer 3

Don't deal with WebElements or XPaths outside PageObjects. The purpose of a pageobject is to encapsulate all the page identifier complexity and return user friendly outputs. You should be able to call a simple action like login("username", "password") without ever dealing with Xpaths, CSS selectors outside.

If you're looking to wrap some of Selenium's more complex functions (getDriver, etc), use an AbstractPageObject to provide more generic functions which all the PageObjects inherit from, or make static functions in a common class.

If you are interacting with a large number of identifiers on your pageObject, and this is undesirable, you have a few different ways of dealing with this:

1) Split your page object up into smaller page objects

Page objects do not have to represent a single webpage, so much as a collection of related elements on a page. Your menu could be a single pageobject, or a table. If you wish to represent the hierarchy you can include it as an public object on the parent page, eg:

public class HomepageObject {

    public MenuPageObject menuPageObject;

    private By element1 = By.id("element-1");
    private By element2 = By.id("element-2");

    public void clickElement1() {
        click(element1);
    }

    ...

}

That way you can access the menu by using eg:

 homepage.menuPageObject.clickStuff() 

The other advantage this has if you have repeated elements on lots of pages, you don't have to keep on including them!

2) Make your identifiers more generic

Alternatively, your elements may be similar, and you can refer to them by a single identifier. The following snippet of code deals with a potentially large list of stuff which share similar IDs. I've used Java 8 streams in this example, but you can just use a foreach loop if you find it easier.

    private By displayedStuff = By.cssSelector("p[id^='stuff-number-']");

    public Optional<String> getStuff(String stuffText){

         // get a list of the elements
         List<WebElement> stuffList = getDriver().findElements(displayedStuff)

         // return the element text which matches stuffText
         return stuffList.stream()
              .map(e -> e.getText())
              .filter(e -> e.contains(stuffText))
              .findFirst();
    }

Your stufflist could be anything: buttons, tables, dropdowns.. there is probably a lot of repetition on your page if you've got that number of elements. Unless your developers are handcoding 100 unique elements too?

3) Consider cutting down the number of elements you have on a page.

If you don't want to deal with 100 different elements, consider how your users might feel!