Visible content locators and i18n in automated tests

I recently read a rebuttal to my post about death to xpath selectors, which raises a point of not using user visible strings in/as selectors to identify elements. The reasoning is that if the time comes to internationalize your site, then your selectors will be brittle as they’re written in a specific language.

Fair point, but if you’re not testing the location of user visible content, then what are you testing? In Australia, I have found it rare (like one project out of about thirty I’ve worked on) that additional languages are supported. But on that one project I used visible user strings to locate objects that weren’t brittle whatsoever. But how? Adam says you can’t do it!

Well, I translate my locators too. That way I am testing both the functionality of the site, the content of the site, and the internationalized content of the site, all at once! No hands.

So how would I do it for my said poor example I used previously?

I’d wrap any selector with something like translate => translate('Buy')).click

and have a translate method defined in a mix-in:

def translate phrase
  #translate some phrase here using same method as AUT

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

3 thoughts on “Visible content locators and i18n in automated tests”

  1. I currently handle i18n for en_us and fr_ca by using constants (ruby of course warns of redef in the same scope):

    case $envHash[:language]
    when ‘en_us’ then
    BUILD_INFO = ‘Build Info’
    when ‘fr_ca’ then
    BUILD_INFO = “Informations sur la version”

    I thought this would be sufficient but apparently our property files have some overlap so in some places the translations are slightly different due to context. Now I think using a method as Alister suggests is a better idea in case you need some context (could unwind the method call stack or something along those lines).


  2. Yeah, lots of ways to internationalise:

    Make an object repository. Eg. page.buy_button.id_how, page.buy_button.id_what, then acquire the relevant object repository.

    Define a module that contains methods for identifications strings. For example:

    Module identifiers
    def buy_button_text

    Then mix in the appropriate language.
    Or store your strings in YAML and do the same.



    1. Thanks for your comment.
      In my experience, the application under test had a list of phrases that were translated, so I hooked into this list (via Jython) and then used it to translate my locators.
      Worked a treat.


Comments are closed.