The PRM, and EDOS-PRM, has also been extended in order to describe the activities of a simple col-laborative testing framework for Java Micro Edition (J2ME) [176] applications 1. The goal of this framework is to provide means to application developers and users to detect if an application will be runnable on a specific mobile phone device and to share this information with other users using the same model of device.
Each mobile phone device running a java virtual machine holds a set of Java Specification Requests (JSR) [90] defining the J2ME configuration of the mobile device. The minimal set of JSRs’ a device runs consists of a given version of CLDC [20] (version 1.0 “Jsr30” [98] or version 1.1 “Jsr139” [97]) and a version of MIDP [122] (version 1.0 “Jsr37” [99] or version 2.0 “Jsr118” [96]). Other JSR packages can be added to the J2ME platform by mobile phone producers such as for instance the Java API for Bluetooth 1.0 “Jsr82” [100].
The issue faced by application developers is that the list of available additional JSRs, and even the list of core JSRs such as the CLDC and MIDP cannot be retrieved through any mean provided by current virtual machines. This leads to situations where needed packages and APIs are not available on the device. Such situation can not be detected prior to running the application, and the latter cannot self test themselves to check if they are runnable on the device.
As code introspection is not available under Java Micro Edition, existing testing frameworks such as Junit cannot be run on it. Thus, The testing framework for J2ME is a framework based on the PRM is made available to achieve these tests trying to provide the best possible workaround to the introspection issue. It provides means to create tests needed to detect a configuration, run them on a mobile phones and to detect if a given user-defined application (or any JSR) will be runnable on the provided platform depending on the results obtained. While performance Testing is not the main purpose of this framework, it has been designed keeping in mind possible extensions to achieve such tests.
10.1 Tackling the configuration retrieval issue
The framework enables information retrieval concerning the configuration of a mobile phone device running a J2ME virtual machine. Gathered information can be split in two sets:
• The properties of the available Virtual Machine
• The list of available JSR’s along with their properties
The workaround to the introspection issue is to get the Java configuration of the mobile phone device by checking the availability of all JSR’s as well as their configuration. To achieve this, the testing
1This work has been part of the master thesis of Nicolas Riou and Simon Pachy, two students from the University of Savoie
117
118 CHAPTER 10. TESTING FRAMEWORK FOR J2ME APPLICATIONS frameworks provides various Micro Edition Tests extending EDOS-PRM Tests. Two types of tests are available, the ones testing the availability of a JSR, and the ones testing its configuration.
The availability of a JSR is tested by running try/catch blocks retrieving specific classes that should be provided by the JSR using the javaClass.forName()method. If a class is not available, the corre-sponding exception is catch and decision can be taken in order to stop the application, modify the way it has to run (by trying to detect an alternative implementation for instance) or just display the result of the test.
try {
// retrieval trial of a specific class of jsr120
Class.forName("javax.wireless.messaging.MessageConnection");
}
catch(ClassNotFoundException){
// jsr120 does not seem to be supported ...
}
The Java virtual machine configuration can be retrieved using theSystem.getProperty()method providing specific parameters. This enables the retrieval of the version of the CLDC being run and of the MIDP as well. Further it also provides useful information about the platform (available memory, total memory, region, etc.) If a JSR is available, some information about its configuration can also be retrieved using the System.getProperty()method or by using a method specific to the underlying API as theGraphics3D.getProperties()method for the “Jsr184”.
10.2 J2ME Testing PRM Extension
The J2ME testing framework has been designed around the PRM and EDOS-PRM which have served as guidelines for Test management and for describing the J2ME testing Activity. Figure10.4depicts how the PRM has been extended, Figure10.1lists the main Artifacts added by this extension and the related activity is presented in Figure10.2. We detail these elements in the following paragraphs.
Figure 10.1: Artifacts of the Micro Edition Testing Extension
Micro Edition Testing Activity. This activity is meant to handle the testing of applications (be it a JSR or a user application) through the push of applications and tests on the server running the ME Testing Activity, the retrieval of these elements by different devices running different configurations, the registration of the results on the server and the retrieval of them for analysis. The testing part itself is running on the device, and thus is external to the PRM extension. Table10.1lists the operations related to the METesting Activity.
10.2. J2ME TESTING PRM EXTENSION 119
Figure 10.2: Activities of the Micro Edition Testing Extension Operation Name Parameters and Return Type Description
register (MEUnit,PMEPropertyMEUnit) Registers a MEUnit application along with corresponding MEProperties to be tested.
retrieveTests (MEUnit):PMEProperty Retrieves all properties to be tested for a MEUnit.
registerResults (MEUnit, PlatformConfiguration, Registers a test report for a MEUnit
MEReport):void running on a PlatformConfiguration.
isRunning (MEUnit, PlatformConfiguration):Boolean Indicates whether a MEUnit is running on a PlatformConfiguration or not.
retrieveConfigurations (MEUnit, Boolean):void Retrieves all configurations on which a MEUnit is running / failing.
retrieveApplications (PlatformConfiguration, Boolean):void Retrieves all applications running / failing on a configuration
Table 10.1: Micro Edition Testing management operations.
AMEUnit, is any application to be distributed in order to be run on a J2ME platform, and which can be tested through the METesting Activity. For instance, JSRs and user applications are specializations of the MEUnit Artifact.
Each MEUnit involves a set ofMEClass, and ofMEPropertywhich can be tested. A MEClass lists the MEMethods which have to be available for the MEUnit to be runnable. A MEProperty, is a property the applications developper wishes to test, such as available memory, a system MEUnit configuration or any other property, such as the configuration of a given API.
MEProperties can be compound of SimpleMEProperties. A set ofMEPropertyTest is associated to each MEProperty; it represents the tests to be run corresponding to it. TheMEUnitTestis a specific MEPropertyTest verifying if the associated MEMethod is available on the tested device.
Once all tests for a MEUnit are run, a MEReportis generated indicating which MEPropertyTests succeeded and which ones failed.
Figure 10.3 illustrates the architecture involving the METesting Activity. A server running this activity offers services to application developers, testers and users. Application developers register applications on the server, and testers can test them on a given configuration. The resulting report is then registered on the server through the activity and can be retrieved by any user. Furthermore, application developers are able to retrieve all results concerning their application to find out which configurations cannot run them. Similarly, users can retrieve a list of all applications that can be run on their device.
120 CHAPTER 10. TESTING FRAMEWORK FOR J2ME APPLICATIONS
Figure 10.3: PRM J2ME Testing Framework scenario
10.2. J2ME TESTING PRM EXTENSION 121
Figure10.4:PRMExtensionfortheJ2METestingFramework
122 CHAPTER 10. TESTING FRAMEWORK FOR J2ME APPLICATIONS