Tuesday Jun 10, 2008

I18n of Junit Testcases

I always believe that Maximum I18n testing should be done before build release to QA. To do that I keep finding out various way to do more and more i18n testing during development.

In that I stuck with this idea of creating Junit testcase for I18n testing. Then I relize it would be good to make Junit testcase itself  I18n. So that input to Junit testcase can be non-english data. It will check the flow of non-english data in application. I have done that for one of module for my product. i.e Portal Server.

Objective

I18n'ed JUnit test case input which will help in doing I18n testing in JUnit.

How to do it?

I18n input of Junit Test case

  • What I mean here by I18n'ed test case is to remove hard coded input(which are localizable) from Testcase and load them using ResourceBundle. So to test those testcases with non english value would be easy (creating a new resource bundle with non-english values).
  • so from developer point of view , instead of hard coding input to test case in Java program they have to read from resource bundle. Then g11n(or developer) team can create resource bundle for other language and integrate in same framework. It will then run the same testcases with non English values. this way we can reuse junit testcases to perform i18n unit testing.

Example

ex. Let me give you example of one of CMS junit testcase
Testcase to create category.
source : CategoryTest.java
Before :

testCategoryCreation{

String categoryName="TestCategoryCreation";

...(code to test creation) ...

}

In this testcase category name "TestCategory" is hardcoded in java program. I have removed this hardcoding and load this value from Resource Bundle.

Now : CategoryTest.java

One new class variable needs to be added.

ResourceBundle rb;

Two new function will be added:


Locale selectLocale(){
return new Locale("en");
}
void loadResourceBundle(){
rb = ResourceBundle.getBundle("CustomResource",selectLocale()) ;
}
CategoryTest(){
loadResourceBundle();
...
}
testCategoryCreation{
String categoryName=rb.getString("TestCategoryCreation");
...(code to test creation)
... }

As shown above, resource bundle will be load once for Test program and it will be used by all the testcases within it. so now when developer run this testcases in english environment and it will work as it was previously.

Now How to leverage this testcase for I18n testing.
Create one interface: I18nTestFramework - which will have one method
Locale selectLocale();

Base Testcase Program has to implement this Interface.


i.e public CategoryTest extends TestCase implements I18nTestFramework

How to provide Localized value for Testcase

Then we need to create New Test program for language in which you want to do I18n testing which will have only one method selectLocale(). ex. "ja".

CategoryJaTest extends CategoryTest {
Locale selectLocale(){
return new Locale("ja");
}
}

Now on whenever Junit framework will be executed. It will execute this test program also and since locale set to "ja" . Resource bundle for japanese will be loaded. which will be used to test all the tests of CategoryTest since it is extended by CategoryI18nTest.

You can create Category<locale>Test java program , ResourceBundle(properties) file for all the language in which I18n testing needs to be done.

(phir milenge ... (cu later)) 

Monday Jun 09, 2008

I18n Best practices for web application- Part 1

I have created clear and concise best practices list for making your application I18n'ed.

General

  • No hardcoded strings
  • Data format I18n
  • Number format I18n
  • Usage of  Apostrophe in Message Format class. 
  • Currency I18n
  • Sort I18n
  • Calendar I18n
  • Read/write file in UTF-8
    • Use methods like :public OutputStreamWriter(OutputStream out, String charsetName); public InputStreamReader(InputStream in, String charsetName)
  • Locale lookup should be correct - Find out what lookup mechanism needs to be used.
  • Send/Receive Locale when communicating with other compoments
  • If any property in property file does not need to be locaized put a comment on top property file.
  • Make sure property file does not have duplicate properties
  • When you use Message format to parse string make sure "'"(aphostrophy) in string is escaped.
  • File system name should be allowed to i18n

JSP Prgoram

  • Encoding of file should be "UTF-8"
    • <%@ page contentType="mimeType ;charset=characterSet ?" | "text/html; charset=UTF-8" %>
  • Use JSTL taglib to include the messages in the JSP file.
  • Request and Response should be in "UTF-8"

Resource Bundle

  • Should not use duplicate key properties file
  • Try to create less number of Property files
  • Try to use same message which already found in other components or even products if it make sense.
  • Do not change layout of message once translated
  • Property file for UI message and Log message should be SEPARATE
  • Message should not be slang or culturally sensitive
  • Always create _en.properties file along with base property file

GUI

  • Each button/textfield should have enough space to accommodate localized sentences
  • Layout and Text rendering
  • Input validation should consider multibyte data

Logging

  • If you are writing a WEB UI, the UI should appear in the client locale, not the server locale. Logging should be done in the server locale to avoid log messages with mixed data from different locales. Use UTF-8 as encoding for the web UI, because UTF-8 supports all languages.

Database

  • Reading and writing data to/from database should be in UTF-8

JUnit Testcase

  • Make sure all your Junit Testcase is I18n'ed. This will help in great way to integrate i18n testing in Unit testing.

AJAX

Refer AJAX I18n

References

About

Mahipalsinh Rana

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today