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

  @browser.link(:text => 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
  phrase
end

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).

    Like

  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
    ‘Buy’
    end
    end

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

    Jared

    Like

    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.

      Like

Comments are closed.