The Disco Blog Welcome Guest | Login or Register

You might get a thrill out of writing Ajax applications (along with wearing bell bottoms), but developer testing them is totally bogue, man. This article examines the inherent challenge of testing hip asynchronous Web applications (especially when it comes to developer testing them early). Check out this month’s “In pursuit of code quality” article, entitled “Unit testing Ajax applications” and find out why it’s easier than expected to tame this particular code quality dragon with the help of the hip Google Web Toolkit.

Don’t forget to let it all hang out at the “Improve Your Java Code Quality” forum while you are at it, man!

I’m finding more and more people are using TestNG and JUnit 4, so I’m curious to see what this copasetic poll brings. This is, obviously, Java specific and does make the assumption you actually write tests, man– of course, you can always select the last option if that’s you.

Also, if you are using another hip framework not listed, I’m interested in hearing about it! Leave a comment, man.

As always, many thanks for your participation!

One of the hippest things about Google’s Web Toolkit is that you can write JUnit tests that can verify asynchronous server side behaviors. What’s more, your copasetic JUnit tests can also be run via Eclipse (not to mention a build process like Ant, etc), which has the effect of decreasing the time between when you code a feature and when you can verify it actually works as expected.

In order to run your GWTTestCase classes in Eclipse, however, you need to do a few steps, otherwise, you’ll get a bunch of nasty things not found errors. Accordingly, to configure Eclipse’s bag to successfully run your JUnit tests, you need to do three things:

1. Create a configuration profile via the Run menu item to launch your JUnit test. Because it’s my bag, I like to create an individual profile for each test, hence, you’ll need to have a fully qualified test class specified. Additionally, ensure the test runner is JUnit 3.
   
2. In the Arguments tab, add -Dgwt.args="-out www-test" to the VM arguments section.
   
3. Lastly, in the Classpath tab, you’ll need to add a few User Entries– namely the directories where your source code and test code lives.
   
4. • This is done by selecting the User Entries item and clicking the button labeled Advanced, then selecting the Add Folders option and then actually selecting the desired folder. It is actually quite easy.

After that, you’re good to go to run those JUnit GWT tests, man!

Creating copasetically Ajax enabled web applications with Google’s Web Toolkit is quite easy due to the ability to write these applications in Java rather than JavaScript. What’s more, GWT applications can be tested via JUnit — actually, to be precise, the backend of an Ajax application can be tested via JUnit. In essence, JUnit GWT tests shouldn’t attempt to validate user actions by clicking buttons, etc, but rather should verify the logic behind those user interactions.

For example, if by clicking a button, an asynchronous call is made to retrieve information from a backend system, a copasetic JUnit test can be written to validate the asynchronous aspects work as designed. This means you should approach writing GWT applications with testing in mind. It is quite easy to write a GWT application that can only be functionally tested– it takes some though as to how you’ll craft it so you can validate logic without crowding it with UI handling.

Regardless of how you actually end up implementing your test, you need to do three things. In fact, the first two steps, if done incorrectly, will cause you much frustration as your tests are guaranteed to fail (even though things compile and you logically write a correct test).

First, in order to create a valid (and by derivation, hip) GWT test case, you must create a class that extends GWTTestCase (or some derivation). What’s more, this test class must live in the same package as the module you’re testing, plus, the test class’s name must follow the pattern of “Test<your module’s class name>.”

For example, if your module is named OrderStatus, then your test case will be named TestOrderStatus. Remember, the test has to be in the same package as well. If OrderStatus is in com.acme.t55.client, then the test class will be logically named com.acme.t55.client.TestOrderStatus.

Second, you must implement the getModuleName method, which returns a String representing the fully qualified XML file name that defines your module in GWT. For example, in the example above, there is a folder structure that is com/acme/t55 in which an XML file lives named OrderStatus.gwt.xml. In this case, the module’s name is com.acme.t55.OrderStatus. Your getModuleName method would look like this:

public String getModuleName() {
 return "com.acme.t55.OrderStatus";
}

As you can probably ascertain man, the first two steps are easy to get wrong; however, things will compile just fine. These are basically semantic requirements of GWT’s GWTTestCase. Get these two incorrect and you have no hope of actually running a successful test.

Finally, step three is to implement a test method, which of course has a name that begins with “test”– this is back to basic pre-JUnit 4 rules. One thing to keep in mind, however, is that server side asynchronous logic’s bag is asynchronous, which means writing normal test code won’t fly– JUnit will cut out before things finish executing.

As such, the GWT comes with a Timer object that allows you to write assertion logic for asynchronous code within a separate thread. Can you dig it?

One of my favorite features of TestNG is its hip parametric testing ability, which allows you to create generic test cases and then vary the test values– you can use parameters from XML files or even use the DataProvider feature for a more rich parameter type. In fact, for awhile, because it’s my bag baby, I’ve been espousing TestNG’s out of the box parametric testing features as a reason to use TestNG as a opposed to JUnit for higher level testing. JUnit 4 , however, now supports parametric tests– and you’ll find that its parametric testing is rather similar to TestNG’s DataProvider.

For example, in TestNG, if I’d like to create a generic test and vary its parameters, I have to do three things:

1. Create a generic test whose parameters are the parameterized values
2. Create a DataProvider method, which feeds the values for the test
3. Link the DataProvider method to the test via the @Test annotation

Hence, I can create a copasetic generic test method as follows:

public void verifyHierarchies(Class clzz, String[] names)
 throws Exception{
  Hierarchy hier = HierarchyBuilder.buildHierarchy(clzz);
  assertEquals(hier.getHierarchyClassNames(), names, "values were not equal");
}

Then I can create a feeder method as follows:

@DataProvider(name = "class-hierarchies")
public Object[][] dataValues(){
 return new Object[][]{
   {Vector.class, new String[] {"java.util.AbstractList",
      "java.util.AbstractCollection"}},
   {String.class, new String[] {}}
  };
}

Note how I have to declare a name for DataProvider, in my case, I dub it class-hierarchies. I can now link the two methods by using the @Test annotation and setting the dataProvider value to the name of my feeder method:

@Test(dataProvider = "class-hierarchies")

That was fairly disco, no? JUnit 4 takes a somewhat similar approach that requires a bit more legwork though:

1. Create a generic test that takes no parameters
2. Create a static feeder method that returns a Collection type and decorate it with the @Parameter annotation
3. Create class members for the parameter types required in the generic method defined in step 1
4. Create a constructor that takes these parameter types and correspondingly links them to the class members defined in step 3
5. Specify the test case be run with the Parameterized class via the @RunWith annotation

If I take the same code above and rework it to use JUnit 4 parameterizations, I first must create the generic test:

@Test
public void verifyHierarchies() throws Exception {
 Hierarchy hier = HierarchyBuilder.buildHierarchy(clzz);
 assertEquals("values were not equal",hier.getHierarchyClassNames(), names);
}

Second, I need to create a dynomite feeder method, which functions much like TestNG in that it requires an Object array with matching parameter types.

@Parameters
public static Collection hiearchyValues() {
 return Arrays.asList(new Object[][] {
  {Vector.class, new String[] { "java.util.AbstractList",
     "java.util.AbstractCollection" } },
  {String.class, new String[] {} } });
}

Note how this method is decorated with the @Parameter annotation, man. Next, because the parameters are of types Class and String[], I create two class members:

private Class clzz;
private String[] names;

Step 4 requires I create a constructor, which links values:

public HierarchyBuilderParameterTest(Class clzz, String[] names) {
 this.clzz = clzz;
 this.names = names;
}

Lastly, make sure you specify at the class level that this test be run with the Parameterized class like so:

@RunWith(Parameterized.class)

As you can see, JUnit makes you jump through a few more hoops, yet the fundamental requirements are quite similar to TestNG’s DataProvider feature. When push comes to shove, I still find TestNG’s semantics much simpler, but it’s nevertheless a disco feature to find in JUnit 4. Dig it?

Performance testing is usually left for last in hip application development cycles– not because it’s unimportant, but because it’s hard to do effectively with so many unknown variables. IBM developerWork’s “In pursuit of code quality: Performance testing with JUnitPerf” makes the case for performance testing as part of the development cycle and shows you two easy ways to do it with Mike Clark’s JUnitPerf framework. Check it out, man!

Because it’s your bag baby, don’t forget to let it all hang out at the “Improve Your Java Code Quality” forum too!

Verifying XML documents has always been the strength of XMLUnit; however, I’ve often found that this JUnit extension is challenging when trying to verify specific portions of a hip XML document. Sure, XMLUnit supports XPath , but XPath is somewhat of a pain (especially if you aren’t an adept XPather).

For example, given the following copasetic XML document, I’d like to verify the exact value of the name attribute of the first Class element.

<DependencyReport date="Wed Dec 31 21:30:00 EST 1969">
  <FiltersApplied>
    <Filter pattern="java|org"/>
    <Filter pattern="junit."/>
  </FiltersApplied>
  <Class name="com.vanward.test.MyTest">
    <Dependency name="com.vanward.resource.XMLizable"/>
    <Dependency name="com.vanward.xml.Element"/>
  </Class>
  <Class name="com.xom.xml.Test">
    <Dependency name="com.vanward.resource.XMLizable"/>
    <Dependency name="com.vanward.xml.Element"/>
  </Class>
</DependencyReport>

Using XMLUnit and XPath, if you’d like to verify that the first Class element’s name attribute value is com.vanward.test.MyTest, you could use the following disco XPath expression:

//Class[1][@name='com.vanward.test.MyTest']

This XPath expression, in concert with XMLUnit, yields the following JUnit test case that must extend XMLUnit’s XMLTestCase due to the call to assertXpathExists:

public void testToXML() throws Exception{
 BatchDependencyXMLReport report =
   new BatchDependencyXMLReport(new Date(), this.getFilters());
 report.addTargetAndDependencies("com.vanward.test.MyTest",
    this.getDependencies());
 report.addTargetAndDependencies("com.xom.xml.Test",
    this.getDependencies());

 assertXpathExists("//Class[1][@name='com.vanward.test.MyTest']",
                report.toXML());
}

In order to verify exact portions of an XML document within XMLUnit, I must have a working knowledge of XPath and must extend XMLUnit’s XMLTestClass. Also too, debugging XPath expressions with XMLUnit isn’t exactly easy either– you end up relying on test case successes or failures to ascertain if your expression is actually valid (but what a great way to verify them, I suppose!). Clearly, verifying exact XML values in XMLUnit is possible, but it could be easier.

Using Groovy, traversing XML documents and obtaining values is, in my opinion, amazingly simple and is much more easy to grasp than XPath. For example, verifying the same exact attribute value can be done as follows:

void testToXML() {
 def report = new BatchDependencyXMLReport(new Date(), this.getFilters())
 report.addTargetAndDependencies("com.vanward.test.MyTest",
    this.getDependencies())
 report.addTargetAndDependencies("com.xom.xml.Test",
     this.getDependencies())

 def doc = new XmlSlurper().parseText(report.toXML())
 def clazzes = doc.Class
 assertEquals("class name should be com.vanward.test.MyTest",
   "com.vanward.test.MyTest", clazzes[0].@name.text())
}

In this example, you only need to work with Groovy’s XmlSlurper class and you’re able to traverse XML nodes as if they are a call graph. As you can see, after the XmlSlurper class is initialized with my document, I am able to grab a reference to the collection of Class elements by asking the root node directly by specifying the element name, which, because it’s my bag, is Class.

Once I have this collection of elements, I can simply reference them similar to XPath, but in Groovy’s case, the access method is 0 based (which is array based access that you learned in CS101). If you look at the first XPath example, it’s 1 based (see the [1] reference?). Accessing attributes is also similar to XPath via the @ symbol and obtaining their value requires the text call.

Given these dynomite semantics, the same XML navigation from the first code example is a much more natural clazzes[0].@name.text(). What’s more, the beauty here is that you’re not dealing with Strings either. Granted, the two examples are slightly different– in the pure Java one, due to the limited API of XMLUnit, I’m forced to assert that an expression exists and in Groovy, I can assert that a value exists. The latter feels more flexible to me.

Using Groovy’s innate XML handling ability means XPath isn’t required. Which is easier to comprehend to you– //Class[1][@name='com.vanward.test.MyTest'] or clazzes[0].@name.text()? The next time you find yourself wanting precise access to portions of an XML document, put Groovy to the test– you’ll find it quite groovy. Dig it?

moreUnit is a copasetic Eclipse plug-in that provides two interesting features:

1. It marks up classes, which have a corresponding developer test
2. It generates a test case stub for desired methods

The tool is heavily focused on JUnit style testing; however, moreUnit works for TestNG as well. As I’ve already advocated, TestNG and JUnit play nicely together, so it shouldn’t be a surprise to see moreUnit complement TestNG.

moreUnit discovers corresponding tests via naming patterns; hence, if you have a hip class named Hierarchy, it’ll scan a project for a HierarchyTest or a TestHierarchy class. Because it’s my bag, I have quite a few code bases that have both TestNG and JUnit tests, I tend to specify TestNG tests via the TestNG suffix and leave JUnit tests with the traditional Test suffix.

Accordingly, I just had to add the new suffix to the moreUnit preference dialog shown below.

If you already have a TestNG test defined for a class (and moreUnit has spotted it), you can right click on non-tested methods and test cases will be generated. Just make sure you’ve unclicked “Create JUnit4 methods” option– otherwise you’ll have to fix an errant JUnit import. With the option unclicked, you’ll be left with a tripping old style JUnit test case (returning void and starting with test).

As you can see in the above figure, you can either right click over an untested method or type Ctrl+U to generate a test case stub.

All that’s left after the stub is created is an annotation (1.5 or 1.4 JavaDoc) and of course, the test logic. Dig it?

During a hip presentation in Boston, I was reminded that one can simulate test groups via JUnit’s test suite mechanism. While I tend not to use suites due to copacetic runners in Ant and Maven, the technique is certainly applicable and for some, it’s more convenient. Plus, by using test suites, one doesn’t need to worry about naming patterns or directory structures (that is, until they need a way to segregate the suites themselves). On the downside, of course, the problem with suites is that they are inherently a manual process– one must add new tests to them pragmatically.

For example, I can define a suite of component tests as follows:

package test.org.acme.widget;

import junit.framework.Test;
import junit.framework.TestSuite;
import test.org.acme.widget.dao.*;

public class ComponentTestSuite {

 public static void main(String[] args){
  junit.textui.TestRunner.run(ComponentTestSuite.suite());
 }

 public static Test suite(){
  TestSuite suite = new TestSuite();
  suite.addTestSuite(SpringWidgetDAOImplTest.class);
  suite.addTestSuite(WidgetFinderTest.class);
  suite.addTestSuite(UserWidgetTest.class);
  suite.addTestSuite(WidgetAccessTest.class);
  return suite;
 }
}

The ComponentTestSuite class defines a suite method, which will reflectively add all tests in the four test classes added in the addTestSuite methods. Therefore, when this class is executed (either via Ant, Maven, the command line, or even TestNG) all component tests are run. Note, if a new component test class is defined, it must be added in this class’s suite method (which requires a recompile).

Interestingly, the JUnit-addons and GSBase projects have some dynamic APIs, which facilitate auto-discovering JUnit tests in directories; however, because it’s my bag, I’d argue that you may be better served by following a directory naming pattern and relying on Ant’s junit task to do the same. Do you dig it, man?

TestNG’s flexible fixtures, parametric testing, and hip grouping facilities make higher level testing a breeze, yet, sometimes I find myself still writing basic unit tests with JUnit (old habits never die, I suppose). But, as I’ve stated before, there’s nothing wrong with using the two smokin’ frameworks in concert– in fact, many code bases already have an extensive collection of JUnit tests; consequently, TestNG can run JUnit tests.

Using TestNG’s testng.xml suite file, you can specify a collection of JUnit tests by creating a new test entry and setting the junit attribute to true. For example, the following suite file runs a series of TestNG tests as well as all the JUnit tests found in the test.com.acme.pdp and test.com.acme.pdp.gsap packages.

<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd">
<suite name="all unit tests suite">
<test name="all unit tests">
 <groups>
  <run>
   <include name="unit"/>
  </run>
 </groups>
 <packages>
  <package name="test.com.acme.pdp.ng"/>
 </packages>
</test>  

<test name="junits" junit="true">
 <packages>
  <package name="test.com.acme.pdp"/>
  <package name="test.com.acme.pdp.gsap"/>
 </packages>
</test>
</suite>

As you can see, this suite file defines a group of TestNG tests that focus on unit tests and another group of JUnit tests found in two different packages.

TestNG isn’t an all-or-nothing choice when it comes to using a testing framework. If you already have an existing suite of copasetic JUnit tests, you can still run them via an Ant task; however, running them via TestNG provides one single report for test results.