Thursday, September 24, 2009

GWT 1.7.1 release fixes Mac OS X Snow Leopard issues

GWT 1.7.1 release fixes Mac OS X Snow Leopard issues: "


If you don't use Mac OS X 10.6 (Snow Leopard), the GWT 1.7.1 release shouldn't interest you much -- you shouldn't see any changes. If you do use Mac OS X 10.6, good news. Running GWT with Java 6 has become simpler. Download it here.



What's in the point release



GWT's hosted mode uses the Standard Widget Toolkit (SWT), which only supports 32-bit operation. Hosted mode must therefore also run a 32-bit version of Java. Mac OS X 10.5 (Leopard) shipped with a 32-bit Java 5 and a 64-bit only Java 6. Java 5 was compatible with the 32-bit SWT bindings, so the GWT SDK directed users to use Java 5 only. With the Snow Leopard release, Apple only includes Java 6, but it now runs in both 32-bit and 64-bit modes.



In short, you can now run GWT on Snow Leopard using the Java command line argument -d32 without further modification. The GWT SDK no longer directs you to only use Java 5, and the ant scripts (including scripts generated by the webAppCreator tool) have been updated to include the -d32 flag where necessary. Also, Linux users will see a more informative error message when a non-32-bit Java runtime is used..



"

Tuesday, September 15, 2009

The Plague of Entropy

The Plague of Entropy: "By James Whittaker

Mathematically entropy is a measure of uncertainty. If there are, say, five events then maximum entropy occurs when those five events are equally likely and minimum entropy when one of those events is certain and the other four impossible.

The more uncertain events you have to consider, the higher measured entropy climbs. People often think of entropy as a measure of randomness: the more (uncertain) events one must consider, the more random the outcome becomes.

Testers introduce entropy into development by adding to the number of things a developer has to do. When developers are writing code, entropy is low. When we submit bugs, we increase entropy. Bugs divert their attention from coding. They must now progress in parallel on creating and fixing features. More bugs means more parallel tasks and raises entropy. This entropy is one reason that bugs foster more bugs ... the entropic principle ensures it. Entropy creates more entropy! Finally there is math to show what is intuitively appealing: that prevention beats a cure.

However, there is nothing we can do to completely prevent the plague of entropy other than create developers who never err. Since this is unlikely any time soon we must recognize how and when we are introducing entropy and do what we can to manage it. The more we can do during development the better. Helping out in code reviews, educating our developers about test plans, user scenarios and execution environments so they can code against them will reduce the number of bugs we have to report. Smoking out bugs early, submitting them in batches and making sure we submit only high quality bugs by triaging them ourselves will keep their mind on development. Writing good bug reports and quickly regressing fixes will keep their attention where it needs to be. In effect, it maximizes the certainty of the 'development event' and minimizes the number and impact of bugs. Entropy thus tends toward it's minimum.

We can't banish this plague but if we can recognize the introduction of entropy into development and understand its inevitable effect on code quality, we can keep it at bay.



"

Friday, September 4, 2009

JUnit 4 Vs TestNG – Comparison

JUnit 4 Vs TestNG – Comparison: "

JUnit 4 Vs TestNG


JUnit 4 and TestNG are both very popular unit test framework in Java. Both frameworks look very similar in functionality. Which one is better? Which unit test framework should i use in Java project?


Here i did a feature comparison between JUnit 4 and TestNG.


1) Annotation Support


The annotation supports are implemented in both JUnit 4 and TestNG look similar.















































FeatureJUnit 4TestNG
test annotation@Test @Test
test method setUp equivalent@Before@BeforeMethod
test method tearDown equivalent@After@AfterMethod
test class setUp@BeforeClass@BeforeClass
test class tearDown equivalent@AfterClass@AfterClass
ignore test@ignore@Test(enbale=false)
expected exception@Test(expected = ArithmeticException.class)@Test(expectedExceptions = ArithmeticException.class)
timeout@Test(timeout = 1000)@Test(timeout = 1000)

The main annoation difference between JUnit4 and TestNG is that


1) In JUnit 4, we have to declare “@BeforeClass” and “@AfterClass” method as static method. TestNG is more flexible in method declaration, it does not have this constraints.


JUnit 4



    @BeforeClass
public static void oneTimeSetUp() {
// one-time initialization code
System.out.println("@BeforeClass - oneTimeSetUp");
}


TestNG



    @BeforeClass
public void oneTimeSetUp() {
// one-time initialization code
System.out.println("@BeforeClass - oneTimeSetUp");
}


2) In JUnit 4, the annotation naming convention is a bit confusing, e.g “Before”, “After” and “Expected”, we do not really understand what is “Before” and “After” do, and what we “Expected” from test method? TestNG is easier to understand, it using “BeforeMethod”, “AfterMethod” and “ExpectedException” instead.


2) Exception Test


The “exception testing” means what exception throw from the unit test, this feature are implemented in both JUnit 4 and TestNG.


JUnit 4



      @Test(expected = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}


TestNG



      @Test(expectedExceptions = ArithmeticException.class)
public void divisionWithException() {
int i = 1/0;
}


3) Ignore Test


The “Ignored” means whether it should ignore the unit test, this feature are implemented in both JUnit 4 and TestNG .


JUnit 4



        @Ignore("Not Ready to Run")
@Test
public void divisionWithException() {
System.out.println("Method is not ready yet");
}


TestNG



 @Test(enabled=false)
public void divisionWithException() {
System.out.println("Method is not ready yet");
}


4) Time Test


The “Time Test” means if an unit test takes longer than the specified number of milliseconds to run, the test will terminated and mark as fails, this feature is implemented in both JUnit 4 and TestNG .


JUnit 4



        @Test(timeout = 1000)
public void infinity() {
while (true);
}


TestNG



 @Test(timeOut = 1000)
public void infinity() {
while (true);
}


5) Suite Test


The “Suite Test” means bundle a few unit test and run it together. This feature is implemented in both JUnit 4 and TestNG. However both are using very different method to implement it.


JUnit 4


The “@RunWith” and “@Suite” are use to run the suite test. The below class means both unit test “JunitTest1” and “JunitTest2” run together after JunitTest5 executed. All the declaration is define inside the class.



@RunWith(Suite.class)
@Suite.SuiteClasses({
JunitTest1.class,
JunitTest2.class
})
public class JunitTest5 {
}


TestNG


XML file is use to run the suite test. The below XML file means both unit test “TestNGTest1” and “TestNGTest2” will run it together.



<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="My test suite">
<test name="testing">
<classes>
<class name="com.fsecure.demo.testng.TestNGTest1" />
<class name="com.fsecure.demo.testng.TestNGTest2" />
</classes>
</test>
</suite>


TestNG can do more than bundle class testing, it can bundle method testing as well. With TestNG unique “Grouping” concept, every method is tie to a group, it can categorize tests according to features. For example,


Here is a class with four methods, three groups (method1, method2 and method3)



        @Test(groups="method1")
public void testingMethod1() {
System.out.println("Method - testingMethod1()");
}

@Test(groups="method2")
public void testingMethod2() {
System.out.println("Method - testingMethod2()");
}

@Test(groups="method1")
public void testingMethod1_1() {
System.out.println("Method - testingMethod1_1()");
}

@Test(groups="method4")
public void testingMethod4() {
System.out.println("Method - testingMethod4()");
}


With the following XML file, we can execute the unit test with group “method1” only.



<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="My test suite">
<test name="testing">
<groups>
<run>
<include name="method1"/>
</run>
</groups>
<classes>
<class name="com.fsecure.demo.testng.TestNGTest5_2_0" />
</classes>
</test>
</suite>


With “Grouping” test concept, the integration test possibility is unlimited. For example, we can only test the “DatabaseFuntion” group from all of the unit test classes.


6) Parameterized Test


The “Parameterized Test” means vary parameter value for unit test. This feature is implemented in both JUnit 4 and TestNG. However both are using very different method to implement it.


JUnit 4


The “@RunWith” and “@Parameter” is use to provide parameter value for unit test, @Parameters have to return List[], and the parameter will pass into class constructor as argument.



@RunWith(value = Parameterized.class)
public class JunitTest6 {

private int number;

public JunitTest6(int number) {
this.number = number;
}

@Parameters
public static Collection<Object[]> data() {
Object[][] data = new Object[][] { { 1 }, { 2 }, { 3 }, { 4 } };
return Arrays.asList(data);
}

@Test
public void pushTest() {
System.out.println("Parameterized Number is : " + number);
}
}


It has many limitations here; we have to follow the “JUnit” way to declare the parameter, and the parameter has to pass into constructor in order to initialize the class member as parameter value for testing. The return type of parameter class is “List []”, data has been limited to String or a primitive value for testing.


TestNG


XML file or “@DataProvider” is use to provide vary parameter for testing.


XML file for parameterized test.

Only “@Parameters” declares in method which needs parameter for testing, the parametric data will provide in TestNG’s XML configuration files. By doing this, we can reuse a single test case with different data sets and even get different results. In addition, even end user, QA or QE can provide their own data in XML file for testing.


Unit Test



      public class TestNGTest6_1_0 {

@Test
@Parameters(value="number")
public void parameterIntTest(int number) {
System.out.println("Parameterized Number is : " + number);
}

}


XML File



<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd" >
<suite name="My test suite">
<test name="testing">

<parameter name="number" value="2"/>

<classes>
<class name="com.fsecure.demo.testng.TestNGTest6_0" />
</classes>
</test>
</suite>


@DataProvider for parameterized test.


While pulling data values into an XML file can be quite handy, tests occasionally require complex types, which can’t be represented as a String or a primitive value. TestNG handles this scenario with its @DataProvider annotation, which facilitates the mapping of complex parameter types to a test method.


@DataProvider for Vector, String or Integer as parameter



        @Test(dataProvider = "Data-Provider-Function")
public void parameterIntTest(Class clzz, String[] number) {
System.out.println("Parameterized Number is : " + number[0]);
System.out.println("Parameterized Number is : " + number[1]);
}

//This function will provide the patameter data
@DataProvider(name = "Data-Provider-Function")
public Object[][] parameterIntTestProvider() {
return new Object[][]{
{Vector.class, new String[] {"java.util.AbstractList",
"java.util.AbstractCollection"}},
{String.class, new String[] {"1", "2"}},
{Integer.class, new String[] {"1", "2"}}
};
}


@DataProvider for object as parameter

P.S “TestNGTest6_3_0” is an simple object with just get set method for demo.



        @Test(dataProvider = "Data-Provider-Function")
public void parameterIntTest(TestNGTest6_3_0 clzz) {
System.out.println("Parameterized Number is : " + clzz.getMsg());
System.out.println("Parameterized Number is : " + clzz.getNumber());
}

//This function will provide the patameter data
@DataProvider(name = "Data-Provider-Function")
public Object[][] parameterIntTestProvider() {

TestNGTest6_3_0 obj = new TestNGTest6_3_0();
obj.setMsg("Hello");
obj.setNumber(123);

return new Object[][]{
{obj}
};
}


TestNG’s parameterized test is very user friendly and flexible (either in XML file or inside the class). It can support many complex data type as parameter value and the possibility is unlimited. As example above, we even can pass in our own object (TestNGTest6_3_0) for parameterized test


7) Dependency Test


The “Parameterized Test” means methods are test base on dependency, which will execute before a desired method. If the dependent method fails, then all subsequent tests will be skipped, not marked as failed.


JUnit 4


JUnit framework is focus on test isolation; it did not support this feature at the moment.


TestNG


It use “dependOnMethods “ to implement the dependency testing as following



        @Test
public void method1() {
System.out.println("This is method 1");
}

@Test(dependsOnMethods={"method1"})
public void method2() {
System.out.println("This is method 2");
}


The “method2()” will execute only if “method1()” is run successfully, else “method2()” will skip the test.


TestNG’s trick of skipping, rather than failing, can really take the pressure off in large test suites. Rather than trying to figure out why 50 percent of the test suite failed, we can concentrate on why 50 percent of it was skipped! Better yet, TestNG complements its dependency testing setup with a mechanism for rerunning only failed tests.


Conclusion


After go thought all the features comparison, i suggest to use TestNG as core unit test framework for Java project, because TestNG is more advance in parameterize testing, dependency testing and suite testing (Grouping concept). TestNG is meant for high-level testing and complex integration test. Its flexibility is especially useful with large test suites. In addition, TestNG also cover the entire core JUnit4 functionality. It’s just no reason for me to use JUnit anymore.


Reference


TestNG

————

http://en.wikipedia.org/wiki/TestNG

http://www.ibm.com/developerworks/java/library/j-testng/

http://testng.org/doc/index.html

http://beust.com/weblog/


JUnit

———–

http://en.wikipedia.org/wiki/JUnit

http://www.ibm.com/developerworks/java/library/j-junit4.html

http://junit.sourceforge.net/doc/faq/faq.htm

http://www.devx.com/Java/Article/31983/0/page/3

http://ourcraft.wordpress.com/2008/08/27/writing-a-parameterized-junit-test/


TestNG VS JUnit

——————

http://docs.codehaus.org/display/XPR/Migration+to+JUnit4+or+TestNG

http://www.ibm.com/developerworks/java/library/j-cq08296/index.html

http://www.cavdar.net/2008/07/21/junit-4-in-60-seconds/


"