Challenges of Testing Wireless Applications
The wide variety of Java technology-enabled devices such as wireless phones and PDAs results in each device running a different implementation of the CLDC and MIDP. Varying display sizes add to the complexity of the testing process. In addition, some vendors provide proprietary API extensions. As an example, some J2ME vendors may support only the HTTP protocol, which the MIDP 1.0 specification requires, while others support TCP sockets and UDP datagrams, which are optional.
To make your application both portable and easy to test, design it using standardized APIs defined through the Java Community Process (JCP), so it will run as-is on devices with different J2ME implementations. If you feel you must use vendor-specific extensions, design your application in such a way that it defaults to the standard APIs if it's deployed on a device that doesn't support the extensions.
Testing Wireless Java Applications
The testing activities described above are applicable to testing wireless Java applications. In other words, you perform unit or class testing, then you integrate components and test them together, and eventually you test the whole system. In this section I provide guidelines for testing wireless applications.
Validating the Implementation
Ensuring that the application does what it's supposed to is an iterative process that you must go through during the implementation phase of the project. Part of the validation process can be done in an emulation environment such as the J2ME Wireless Toolkit, which provides several phone skins and standard input mechanisms. The toolkit's emulation environment does not support all devices and platform extensions, but it allows you to make sure that the application looks appealing and offers a user-friendly interface on a wide range of devices. Once the application has been tested on an emulator, you can move on to the next step and test it on a real device, and in a live network.
Usability Testing
In usability testing (or GUI navigation), focus on the external interface and the relationships among the screens of the application. As an example, consider an email application that supports entry and validation of a user name and password, enables the user to read, compose, and send messages, and allows maintenance of related settings, using the screens shown in Figure 1, among others.
Network Performance Testing
The goal of the next type of testing is to verify that the application performs well in the hardest of conditions (for example, when the battery is low or the phone is passing through a tunnel). Testing performance in an emulated wireless network is very important. The problem with testing in a live wireless network is that so many factors affect the performance of the network itself that you can't repeat the exact test scenarios. In an emulated network environment, it is easy to record the result of a test and repeat it later, after you have modified the application, to verify that the performance of the application has improved.
Server-Side Testing
It is very likely that your wireless Java applications will communicate with server-side applications. If your application communicates with servers you control, you have a free hand to test both ends of the application. If it communicates with servers beyond your control (such as quotes.yahoo.com), you just need to find the prerequisites of use and make the best of them. You can test server-side applications that communicate over HTTP connections using HttpUnit (a Java API for accessing web sites without a browser. It is ideally suited for automated unit testing of web sites when combined with a Java unit test framework such as JUnit, which I'll discuss in the next section. You can also measure a web site's performance using httperf, a tool designed for measuring the performance of web servers).
Conclusion
Testing is a systematic approach to finding errors in programs. It is a very challenging process in the wireless application market because an application is developed on one platform and deployed on ones that are vastly different. The process is complicated even further by the availability of a wide range of devices that implement different versions of the KVM, CLDC, and MIDP, and that provide extension APIs not available on all devices. To achieve the maximum portability, verify that your applications use the standard APIs.
