Better Software - November 2008 - (Page 28)

code (“hosted mode”) or compile and run all your Java code as JavaScript (“Web mode”). The GWT team recommends that you run your tests both in hosted mode and Web mode, since there are a few subtle differences between Java and JavaScript [1], which could cause unexpected behavior. Being able to test native JavaScript code in your Java JUnit tests is great, but there are some limitations. First, the normal browser-event mechanisms don’t work as expected in test mode. For example, you can’t programmatically click a button and expect the corresponding event handlers, such as onClick(), to fire. Selenium [2], the open source testing tool, can control a real browser and is a helpful alternative in this situation. There are also performance considerations; the tests are slower than standard JUnit TestCases. Running a GWTTestCase forces a compilation of the source code in your module, which incurs an initial startup delay. Furthermore, each individual test method is wrapped by logic that starts up and shuts down the headless browser, which can take several seconds. Some testers would call these integration tests, not unit tests, since they involve other systems, cross language boundaries, and are slow to execute. So when should you extend a standard JUnit TestCase vs. a GWTTestCase? In general, you should prefer standard JUnit TestCases because they run orders of magnitude faster than a GWTTestCase. If your code executes native JavaScript, however, or uses the libraries supplied with GWT, then your test must extend GWTTestCase. The upshot is that even if you simply instantiate a widget in the code being tested, you will have to test this using a GWTTestCase. You might try to find another design approach that avoids this native code requirement, such as moving the logic to another class. Figure 1: The first iteration of the UI for the booking application Figure 2: Object responsibilities and interactions for the booking application gui design Patterns To build a testable GUI application, there are several design patterns and techniques you can use. All of them focus on one core principle: Move as much logic as possible out of the view and into other, more easily testable layers. One common pattern is known 28 BETTER SOFTWARE NOVEMBER 2008 as Model-View-Presenter, where a presenter object acts as a mediator between the view (GUI) and model objects and instructs the view layer to change states in response to user input or model changes. Martin Fowler has described a few variants of this pattern in his bliki [3], including Supervising Controller and Passive View. Both patterns push all logic- and event-handling code into the presenter, but they differ in how much the view knows about the model. Presenters hand the model objects directly to the view in the Supervising Controller pattern; then the view picks the appropriate information to display. In Passive View, the view layer knows nothing www.StickyMinds.com about the model objects, and the presenter communicates model details to the view in terms of primitives, such as strings and numbers. Michael Feathers’s paper “The Humble Dialog” [4] provides a good introduction to the subject, and Martin Fowler’s bliki is a good resource for the other variations. example To illustrate some of these concepts, let’s take a look at building a small portion of an application. For this example, suppose we’re building an online application for booking meeting rooms at a conference center. A user will need to specify some details about the meeting, http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - November 2008

Better Software - November 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Getting Agile with User-Centered Design Google Web Toolkit Simple Summaries of Complex Projects Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.