What practices exist for locale-specific unit testing?

Question

We recently discovered a locale specific issue in our application and while it was easy to fix (once we figured out what was going on), it got the team I'm on thinking about unit testing practices in this regard.

We would like to catch these issues sooner, ideally before they're discovered by a customer, and we want to protect ourselves from reintroducing locale specific bugs in the future, but duplicating every unit test in at least one other culture seems like a lot of overhead.

How do you or how would you approach multi-locale unit testing?

Answer 1

Generally you will not need to duplicate every unit test. You should identify what is really dependent on the locale (good checklist is here). Many things related to internationalization are subject to the higher level of testing then unit-test.

If you are dealing with the string data that may come in different encodings, then you can utilize "data driven testing", i.e. passing data in different encodings to the same test method. For Java the TestNG is best suitable for this.

Another possible problem is the date/time formatting and parsing. Most locales uses : to separate time elements, but there are ones who uses dots and Brazilians uses h m and s (12h15m30s). This also can be used by passed data in different locales - you do not need to test all of them.

And testing GUI with right-to-left locales is usually not a subject of unit testing.

The bottom line is that you need to identify what data in your unit tests is locale-specific and use data-driven testing (data providers) to supply this data to your tests.

Answer 2

Here are few suggestions:

• Always develop on a machine with local settings different from your main target audience. It will helps you find bugs related to dates, currency, and every numerical formatting issue very quickly. Do the same with your build server, put it in Brazil or Vietnam (not physically, just the settings).

• Use accents and special characters in your test title, strings, etc. in your unit tests. The most common internationalization issue I get with software I use (not those I develop) is with é and è or even ç in french. Put them in every string you use in your tests. Use a common word you use all the time like brèç©

• Don't forget to use accents and special charts in paths as well. Visual Studio.NET itself still has many issues with that! You should access create such directories and read/write from them in your tests.

• If you use Visual Studio .NET, in project properties, under Code Analysis, enable Globalization Rules. Most common issues will generate a warning at compilation.

• Hire a foreigner in your team.