June 12, 2012

GWT Unit Tests

About a year ago, I spent about two months trying to figure out how to integrate GWT's unit tests within a custom web container. The problem what that we had an embedded jetty server which which had access to the full ClassLoader (i.e. disabled J2EE compliance). 

In development mode, this wasn't an issue because there is two easy workarounds. I started out by using the -server option and build a customer ServletContainerLauncher which allowed my to start the whole application (jetty server and all) within the dev-mode. This solution worked fine and even supported the "restart/reload" option with eclipse but after working with GWT for a while, I realized this was an overkill. Instead, I realize that you can use the -no-server option to achieve the same thing. So instead of trying to force our application to run the GWT container, I started up our application and the GWT engine in dev mode. GWT engine then generated the javascript and dumped it in our applications webapp directory. When the browser hit our web server it would then serve up the html and js files that GWT generated but because the ?gwt.codesrv= argument existed on the URI, the GWT browser plugin would then communicate to the GWT engine. Of course, in this mode the reload/restart button didn't work in eclipse but one advantage of this solution is you can easily swap between production and dev mode.


Unfortunately, getting JUnit tests running was not as easy. So in order to get junit tests running within our own servlet container, I was forced to patch the JUnitShell class. The patch does the following:


  • Add a -server option to the enable a custom ServletContainerLauncher
  • Created a CustomerLauncher that subclasses the ServletContainerLauncher. This allowed for the JunitTest to resolve the Jetty container and map the servlets from the my GWT module into the junit modules that was generated. See line 148

The patch is attached to the following google ticket.


No comments: