Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

I have begun with automation for a product which is in one language and soon to be ported in another. The only good thing is - Test Automation is just begun.

So there are two things which worry me - hard coded Strings (app title, alert messages etc) in Test Scripts and Test Data which should be keyed in depending on locale.

I was thinking of having a global variable which indicates the locale for which test is to be executed and then deciding on String/test data to be used in test method.

Now consider that I externalize the String I have in tests and then decide string of which language is to be used in my test method, so I could do something like -

 public void myAweSomeMethodWorkingInAllLocales() { 
   if(locale is fr) {
     testDataFile=privateLocation/frTestDataForThisLocale
     testStringFile=privateLocation/frAPPStringForThisLocale
   } else if (locale is in) {
     testDataFile=privateLocation/inTestDataForThisLocale
     testStringFile=privateLocation/inAPPStringForThisLocale       
  }
  //Carry Out my Super tests here
  }

But I find it little cumbersome to do so in each test method of mine. Could I improve it?

share|improve this question
add comment

4 Answers

up vote 4 down vote accepted

There are many other aspects to testing internationalization and localization, and other ways to attack problem I think you are trying to solve, but I will restrict my answer to your specific question.

I suggest removing all hard-coded locale references from your test suite, and instead having the entire test suite test against a single locale that you specify via a command-line argument, property file, or environment variable. Then, instead of doing this...

if(locale is fr) {
  testDataFile=privateLocation/frTestDataForThisLocale
  testStringFile=privateLocation/frAPPStringForThisLocale
} else if (locale is in) {
  testDataFile=privateLocation/inTestDataForThisLocale
  testStringFile=privateLocation/inAPPStringForThisLocale       

}

... I would do this:

 testDataFile=getTestDataForThisLocale(the-locale-we-are-testing-this-time)
 testStringFile=getAppStringsForThisLocale(the-locale-we-are-testing-this-time)

If you want to test two locales, you can run the test suite twice. This gets you out of the business of embedding locale-dependent if-statements throughout your test suite.

share|improve this answer
    
far cleaner to read and I suppose implement also. –  Tarun Aug 8 '11 at 6:13
add comment

If your application supports Unicode then I really don't understand the reason for segregating input or output test data by language or language family. If somewhere in your product code you thunk between ANSI and Unicode then you could certainly have some issues and testing with a broad range of chars across the Unicode spectrum will flush out those problems sooner than by language based resources.

But, this is especially the type of situation where random test data generation becomes valuable; even locale specific test data. Instead of jumping through a bunch of else if's or switch/case statements you can pass the 'locale' argument to "GetString()" method that takes a language/locale parameter.

A well designed random string generator can generate strings by language family, language, etc, or a mix. I am also working on one now that will generate look like real sentence, or take bodies of text from locale specific docs, randomize the words and spit out sentences, paragraphs, etc.

Alternately, if you are using static files to read in your test data you can also let the system do the work. If you have a file named with each locale / language code you can detect the current language code programmatically, then just read in that file.

            string testDataFileName = "testdata.txt";

        CultureInfo ci = CultureInfo.CurrentCulture;
        string isoLanguage = (ci.ThreeLetterISOLanguageName);

        string path = Path.GetFullPath(
            Environment.GetFolderPath(Environment.SpecialFolder.Desktop));
        try
        {
            using (StreamReader readFile = new StreamReader(
                Path.Combine(path, string.Concat(isoLanguage, testDataFileName))))
            {
                //do stuff
            }
        }
        catch (FileNotFoundException)
        {
            // handle file not found exceptions
        }

In this case I am getting the 3 letter ISO language name (the complete list is at http://www.loc.gov/standards/iso639-2/php/code_list.php), and prepending it to a filename or extension and then using stream reader to open and read in the file's contents.

This eliminates the need for passing command line args at the launch of the test, and enables growth into new locales as needed by simply adding new satic data files.

share|improve this answer
add comment

I blogged about this a while back here. These are some of the pitfalls I encountered when developing test automation solutions for a product available in 28 languages.

I would NEVER hard code any strings - really your automation shouldn't depend on them at all. Depending on the architecture of the product under test, you should get buy in from development to ensure that each control on the UI has a unique, static identifier. For example, for a HTML based UI, the 'id' attribute could be used. Win32 controls can be assigned identifers also I believe.

Maintaining strings files is a bad approach, if the strings change (for example in a new version or a bug fix due to bad localization), you'll need to update such files.

If you use a unique identifer of some sort, your automation will possibly work for many versions, unless in the event of a major UI overhaul.

share|improve this answer
1  
Guess what, I read your blog and commented (though not yet visible) before posting this question. I see the point about unique identifies. But what if you had to check validation messages in different languages, How do you handle that? Now would you keep different String file, one for each locale? –  Tarun Aug 8 '11 at 6:16
    
Yes, in that scenario, we would maintain a strings file per language, but normally this is just a couple of strings. Even doing this we've had some problems as error messages change from version to version, or some the tech writers decide to change an error message to be more descriptive. I guess in situations like this, there's no other choice, (unless you've got some serious developer buy in and error dialogs are assigned an ID based on the content they contain for example). BTW, comment is approved now ;-) –  Jimmy C Aug 8 '11 at 16:04
2  
our errormessages always have a text and an error-id (which is internally used to get a localized-string-format-string). So our errors are validated agaist error-id instead of error-text –  k3b Aug 8 '11 at 20:54
    
@k3b A great approach also. –  Jimmy C Aug 9 '11 at 21:18
add comment

Years ago, I took a similar approach to testing under different locales. It worked well for me.

I used something like this during the internationalization portion of the project: http://strazzere.blogspot.com/2010/04/pseudo-translation-of-strings-as-aid-to.html

I also externalized all the resources (strings), and had them translated for me by a professional translator.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.