Agile User Interface Development

Agile User Interface Development

Overview

"If you're not doing Agile,you're in the past." This is the message of the recent SD Best Practices 2004 conference. Agile processes like XP and Scrum are becoming pervasive in the world of software development. Agile is a sea change,refocusing software developers on quality and speed. Its impact on the practice of software development is already being compared to that of object-oriented design. However,one area of effort has been slow to change: development of the graphical user interface (GUI). Since most software includes some type of GUI,and a good percentage of software development is completely GUI-centric,applying the advantages of Agile to GUI building is of key importance.

What is preventing people from building GUIs in an Agile way? Whether their application is web-based or a desktop application,most developers don't do test-driven development (TDD) of the user interface. This is for a simple reason: unit testing GUI software is hard. Tests that exercise the GUI can be tedious and error-prone,involving complex code to simulate user events,wait while events propagate and controls redraw,and then attempt to check the state as it would appear to the user. Agility depends on doing TDD,but effective tests of specific behaviors are difficult to write for the GUI. The quality and design benefits of Agile have yet to be fully realized on the GUI side of the cube farm.

Agile practices are creeping into this domain. Tools for unit testing GUI elements are proliferating. The JFCUnit framework tests GUIs built using Java Swing. Web-based GUIs can be tested with HTMLUnit,HTTPUnit,jWebUnit,and similar tools. Many GUI builders and toolkits have associated unit testing tools,such as VBUnit for Visual Basic and QtUnit for Qt.

The tools exist,but the process is still emergent. In TDD,each code change is preceded by a unit test of the new behavior. In GUI development,many changes are just tweaks to the visual appearance,such as changing element positions,text,or color. You might add a button,create a menu item,or construct a dialog. But how and why would you test these kinds of changes? Testing every label or color value would be insane. Likewise,for standard elements like buttons and fields,it's pointless to test their generic behaviors,such as responding to mouse movements,key presses,clicks,and so forth. They are not likely to break. Questions of what to test just increase the innate difficulty of building GUI tests.

The critical question: how do you do test-first GUI development? The answer lies in how the GUI code is structured. Agile gurus such as Kent Beck and David Astels suggest building the GUI by keeping the view objects very thin,and testing the layers "below the surface." This "smart object/thin view" model is analogous to the familiar document-view and client-server paradigms,but applies to the development of individual GUI elements. Separation of the content and presentation improves the design of the code,making it more modular and testable. Each component of the user interface is implemented as a smart object,containing the application behavior that should be tested,but no GUI presentation code. Each smart object has a corresponding thin view class containing only generic GUI behavior. With this design model,GUI building becomes amenable to TDD.

Example: Building a Login Dialog

Let's walk through an example of how to develop a GUI dialog using TDD and the smart object/thin view code design model. First,let's consider the graphic design of the dialog. Agile development calls for minimal up-front design,letting the software architecture evolve through multiple development cycles,but this approach isn't a good idea for GUI design. Designing a user interface is a creative process that should be approached formally,with sketches,prototyping,and usability testing. So,although the code behind the GUI can be designed iteratively using TDD,a sketch of the visual design is a smart first step. The basic design for the login dialog is sketched in Figure 1.

Figure 1. GUI design sketch for login dialog

The dialog is simple,containing user name and password fields,corresponding static text labels,and Login and Cancel buttons. As an initial outline of its behavior,let's decide that a successful login causes the dialog to close,but it remains open in case of login failure. The Cancel button also closes the dialog.

The basic smart object/thin view class design for the code implementing the dialog is shown in Figure 2.

Figure 2. The classes LoginDialog and LoginDialogView

The smart object class LoginDialog will contain a method corresponding to each functional behavior of the dialog. The thin view class LoginDialogView will only contain simple display-related code,and get/set methods to read or set the displayed information. With this approach,only the complex functionality in LoginDialog needs to be unit tested. We can be pretty confident that the simple behavior in LoginDialogView will work.

The first component to build is the smart object LoginDialog. It needs a corresponding test class LoginDialogTest. The first test method will verify the login method,as shown in Figure 3.

Figure 3. The smart object LoginDialog and its test class LoginDialogTest

As the test-first development process dictates,the unit test is written first. The test anticipates and defines the design of the functionality being tested. We need to take a user name and password,and return a login success or failure. A sensible interface to do this is:

boolean login(String username,String password);

The test class LoginDialogTest will test this function. Example 1 shows its initial implementation in the file LoginDialogTest.java.

LoginDialogTest.java import junit.framework.*; public class LoginDialogTest extends TestCase { public void testLogin() { LoginDialog dialog = new LoginDialog(); assertTrue( dialog.login("user","passwd") ); } }

This test builds on the JUnit base test class TestCase. The test method testLogin() creates an instance of LoginDialog,calls its login() method,and asserts that the result is true. This code will not compile,since LoginDialog doesn't exist. Following the TDD process,LoginDialog should be stubbed,the code compiled,and the test run to verify that it fails as expected. Then,LoginDialog is given the minimum implementation to pass the unit test,following the Agile mantra of doing "the simplest thing that could possibly work." Example 2 shows the initial version of LoginDialog with the minimum code to pass the unit test,implemented in the file LoginDialog.java.

LoginDialog.java public class LoginDialog { LoginDialog() {} public boolean login(String username,String password) { return true; } }

The code is built using the following commands:

javac -classpath ".;junit.jar" LoginDialogTest.java javac -classpath "." LoginDialog.java

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!