Interacting with web elements

This post is part of the Pride & Paradev series.

When writing automated acceptance tests for a web application, there are a couple of different ways to identify and interacting with elements, two of the most common are using strings or values.

Take this simple select list of tea:

<select id="tea">
<option value="bop">Broken Orange Pekoe</option>
<option value="eg">Earl Grey</option>
<option value="eb">English Breakfast</option>
<option value="darl">Darjeeling</option>

This renders as:

Select List Rendered

There are two ways to automate choosing something from this select list: by string, like “Broken Orange Pekoe” or by value, like ‘bop’.

Use strings to interact with elements

The benefit of using strings to identify and interact with elements is that it’s how a user uses your web application: a user will select “Darjeeling” from your drop down so why shouldn’t your automated tests do the same.

If your web application is internationalized and you wish to run your automated tests in a different locale, you will also need to translate your selection as this will change with your locale that you set.

Modern JavaScript frameworks like Knockout often don’t generate values for select lists, so in this case you need to use strings to interact

Use values to interact with elements

The benefit of using values to interact with elements is that values are the most resilient to change. For example, if “Earl Grey” was changed to “Earl Gray” and you are automating based upon value, then your automated acceptance tests will continue to work as they will use the value ‘eg’.

This is also the best option if your web application is internationalized and you run your automated acceptance tests against a different locale: whilst “English Breakfast” may display “Petit Déjeuner Anglais” in French, it’ll still happily be selected by using the value ‘eb’.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

7 thoughts on “Interacting with web elements”

  1. Alister,

    Good points. But do you suggest actually writing the code to select elements in the ways you have suggested?

    I don’t know of a good way to select an element by text in WebDriver except maybe by using some unreadable xpath. Selecting by value is no problem (you can use the more readable CSS selectors). Do you mind including some real-world code that shows how you would actually select these elements?




  2. Hi Brain,
    This page has many good examples.

    Hi Alister,
    Good points about the web element interaction. To me, I believe that it is better to use “Value” to select options. It is more stable and reusable. Meanwhile, the text of options should be used for verification, but not a way to select options.

    my 2 cents.


  3. My two cents:

    One way you can get the best of both worlds is if you use CSS & XPath locators. Simply use an OR operator to combine matching by value & by text, so if either one matches, you’ve found the locator.

    For CSS: “cssByValueLocator, cssByTextLocator”, the comma is the OR operator
    For Xpath: “xpathByValueLocator|xpathByTextLocator”, the pipe is the OR operator

    And Brian, you can select by text with XPath (even complex ones) without being ugly if you know how to work with XPath, for example:

    //td[@class=’results_service’ and contains(text(),’Extra Cover’)]/following-sibling::td[@class=’price’]

    matches the TD tag with class=price that (immediately) follows a TD who’s class=results_service & has text “Extra Cover”.

    Matching by text can also be done with CSS, but it’s not standard CSS3/CSS2 and only works through Sizzle/JQuery (that’s too bad :( ).


  4. Also wanted to mention, regarding Jun’s comment, you can do both data validation (of the text of the select element) and finding locator in one shot by locating by text. As you’re already locating by text, if the element is present, that already verifies the text for it (or on the screen). So in most cases, an assert that it is present (true/false) will be equivalent to asserting expected text against the getText value of the element. Perhaps the locator is a bit brittle in this case as a tradeoff for being able to sometimes save lines of code in assertion (especially, in cases where you need to check element is present anyways).


  5. I had an interesting experience at a job with select box (drop down) troubles… they built in GXT… so the html was generated. The drop downs used in the web application were not defined as “select,” but rather they were defined as “text” (i.e. text fields.) they were also read only. What that meant was, watir-webdriver can’t use the select method on these fields, and must use the text_field method to use it… I wasn’t able to use the selection to grab values, and since it’s read only, I couldn’t type values into the field either. I ended up with a work around, but it’s somewhat awkward… I pass keys :arrow_down, :return to select an item in the list. It’s crazy, I know, but outside of reworking the watir-webdriver methods I didn’t know how else to handle it.

    I was able to get the dev team to make changes in the code, but this change couldn’t be introduced. So I had to work around it as a constraint. So if a drop down had multiple selections – like a language drop down having (English, Spanish, French.) My cucumber test would be a scenario outline with the values example values of English, Spanish, French, and the step definition would be an if statement… if “English” was passed through to the step_definition then it would send keys :arrow_down, :return. If “Spanish” then send keys 2.times{:arrow_down} :return, etc.


      1. I’ve come across similar but different issue where the drop down was not a select nor text field but a bunch of divs that are emulating a drop down. So you’d have to do a bunch of mouse/element clicking to select the right value. In RC had to resort to mouseDown, mouseUp method combos to get it to work. Luckily in my case, in these designs, the div collection that emulated a select always included a hidden text field element that actually stored the value for the selection. So with WebDriver, rather than making test code complex & brittle, and having to test it slow & realistically, I just set the value via Javascript (since it’s a hidden element, can’t manipulate directly) and that does the trick for me. Same thing if need to read back the value. I find that satisfactory, unless one needs to specifically test the drop down UI functionality.


Comments are closed.