The Disco Blog

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?