System and method Xlet and applet manager testing

An invention is provided for an application manager testing interface that provides a public API usable by testing software. The application manager testing interface allows testing software to issue commands to an application manager to test the life cycle and state management abilities of the application manager. A testing program capable of providing commands to test a life cycle of a dependent program controlled by an application manager is provided. In addition, an application manager testing interface is included that is in communication with the testing program and the application manager. The application manager testing interface is capable of receiving the commands from the testing program and providing the commands to the application manager. In this manner, the application manager can control the dependent program based on the commands. In one aspect, the testing program can be controlled by the application manager. For example, the application manager can be an Xlet manager and the testing program is an agent Xlet, or the application manager can be an applet manager and the testing program can be an agent applet.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to computer program testing, and more particularly to applet and xlet manager software compatibility testing.

2. Description of the Related Art

Java™, originally developed by Sun Microsystems, is an object-oriented, multithreaded, portable, platform-independent environment used to develop, test, and maintain software programs. As used hereafter, any reference to Java will be understood to contain the appropriate trademark reference owned by Sun Microsystems Inc. To assure platform-independence, Java implementations are often tested using methods that confirm consistency across multiple hardware platforms, operating systems, and other implementations of the same Java technology specification. This type of testing generally is referred to as compatibility testing.

FIG. 1is an illustration showing a conventional Java based software environment100. Java accomplishes platform independence using a Java virtual machine (JVM)104, which resides above the native operating system (OS)102. In addition, the Java based environment can include an application programming interface (API)106that provides additional functionality to Java applications108executing on the JVM104.

Generally, the Java program108comprises machine-independent byte code, which is interpreted by the JVM102before being run on a native instruction set of the target processor. In addition, the API106can provide libraries of functions, which the Java application108can use to perform specific tasks. In the example ofFIG. 1, the Java application108is essentially a “standalone” program, which can create what it needs to execute. That is, the Java application108generally does not need other applications to execute properly.

Because of its “standalone” nature, a testing program can easily perform compatibility testing on the Java API106by loading a test that calls Java API106into JVM and monitor the test's behavior. However, not all Java based programs are “standalone” applications. For example, Java programs have found extensive use on the World Wide Web, which is the Internet's multimedia information retrieval system. These programs include smaller programs, known as applets, that run in a Java enabled Web browser or applet viewer. Such Java applets require an applet manager, such as the Java enabled browser, to execute properly.

FIG. 2Ais a block diagram showing a conventional Java applet based software environment200. Similar toFIG. 1, the conventional applet based software environment200includes an OS layer102, on which a JVM104and API106are executed. However, the applet based software environment200also includes an applet manager110, which in the example ofFIG. 2Ais a Java enabled browser, that provides an environment for applet programs112to execute. In operation, the applet manager110controls the state and execution of the applets112. That is, the applet manager110determines when to load, start, and stop each applet112. For example, a particular input applet112may be designed to create and open a small window that allows a user to input data. In this case, the applet manager110(browser) may load the input applet112in response to a user making a particular selection on the browser110to enter data.

Similar to applets, Java based software for small devices often require a separate software manager to execute properly. Generally, Java software for small devices is developed using Java 2 Micro Edition (J2ME), which is an edition of Java 2 for small devices such as PDAs and consumer appliances. One type of program often used in J2ME is the Xlet, which is a program similar to an applet, which executes within an Xlet manager.

FIG. 2Bis a block diagram showing a conventional J2ME Xlet based software environment250. Similar toFIG. 2A, the conventional Xlet based software environment250includes an OS layer102′, on which a JVM104′ and API106′ are executed. However, the Xlet based software environment250includes an Xlet manager254that provides an environment for Xlet programs256to execute. As with the applet manager ofFIG. 2A, the Xlet manager254controls the state and execution of the Xlets256. Hence, the Xlet manager254controls when each Xlet is loaded, paused, and active.

Unfortunately, because of the management software requirements, programs such as the applets112and Xlets256ofFIGS. 2A and 2Bare not easily accessible by testing programs. In particular, these programs have their life cycles managed by the applet manager110or the Xlet manager254software via methods defined in a life cycle interface that the applications implement. However, there is no public application manager API available where the life cycle for the applets or Xlets is defined. Hence, there is no way for the testing program to request the application manager to change the state of applets or Xlets, or query the application manager for the state of applets or Xlets.

In view of the foregoing, there is a need for a testing method that is capable of testing the application management functionalities of an application manager, such as an applet manager or Xlet manager. The methods should provide a mechanism for testing software to test an application manager's ability to manage the life cycles of the programs under its control.

SUMMARY OF THE INVENTION

Broadly speaking, the present invention fills these needs by providing an application manager testing interface that provides a public API usable by testing software. The application manager testing interface allows testing software to issue commands to an application manager to test the life cycle and state management abilities of the application manager. In one embodiment, a system is disclosed for testing an application manager. The system includes a testing program capable of providing commands to test a life cycle of a dependent program controlled by an application manager. In addition, an application manager testing interface is included that is in communication with the testing program and the application manager. The application manager testing interface is capable of receiving the commands from the testing program and providing the commands to the application manager. In this manner, the application manager can control the dependent program based on the commands. In one aspect, the testing program can be controlled by the application manager. For example, the application manager can be an Xlet manager and the testing program can be an agent Xlet, or the application manager can be an applet manager and the testing program can be an agent applet. Optionally, a test harness can be included that is in communication with the testing program. In this aspect, the test harness is capable of providing test commands to the testing program. Generally, the commands provided to the application manager can request the application manager to change a state of the dependent program. Also, typically at least one command provided to the application manager can request the application manager to provide state information for the dependent program.

In an additional embodiment, a computer program embodied on a computer readable medium for facilitating testing of an application manager is disclosed. The computer program includes a code segment that receives test commands from a testing program, and a code segment that translates the test commands into corresponding application manager commands that are capable of being processed by an application manager. Further, a code segment is included that provides the application manager commands to the application manager. In this manner, the application manager can process the application manager commands. In one aspect, the application manager can be an Xlet manager, which changes the state of and/or provides state information for an Xlet in response to receiving an application manager command. In an additional aspect, the application manager can be an applet application manager, which changes the state of and/or provides state information for an applet in response to receiving an application manager command.

A method for testing an application manager is disclosed in a further embodiment of the present invention. Test commands are received to test a life cycle of a dependent program controlled by an application manager. Then, the test commands are translated into corresponding application manager test commands capable of being processed by an application manager. The application manager test commands are then provided to the application manager, which processes the application manager commands. The test commands can be received from an agent test program executed using the application manager. As above, the application manager can be, for example, an Xlet manager, and the test commands can be requests to the application manager to change a state of an Xlet. Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

An invention is disclosed for an application manager testing interface that provides a public API usable by testing software. The application manager testing interface allows testing software to issue commands to an application manager to test the life cycle and state management abilities of the application manager. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order not to unnecessarily obscure the present invention.

Embodiments of the present invention generally can be used during compatibility testing of application managers. As mentioned previously, compatibility testing refers to the methods used to test an implementation of a Java technology specification in order to assure consistency across multiple hardware platforms, operating systems, and other implementations of the same Java technology specification. When this assurance is accomplished by means of a formal process, application developers can be confident that an application will run in a consistent manner across all tested implementations of the same Java technology specification. This consistent specification-based behavior is a primary function of compatibility testing.

Currently, Java technologies can be grouped into three editions: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE), and Java 2 Micro Edition (J2ME). As with most other types of Java software, a new Java technology should be tested to assure consistency across multiple platforms. This testing is generally performed using compatibility testing.

J2ME categorizes devices that are similar into various classes. For example, there are classes for personal digital assistances (PDAs), televisions, set-top boxes, automobiles, and other device types. Personal Basis Profile (PBP) is one of the technologies in J2ME that provides a set of Java API targeted at advanced PDAs that generally include graphics, file systems, and network connections.

FIG. 3is a block diagram showing a PBP environment300, in accordance with an embodiment of the present invention. The PBP environment300provides a J2ME application environment for network-connected devices supporting a basic level of graphical presentation. In particular, the PBP environment300provides a standard J2ME profile for devices with relatively limited resources and basic GUI facilities. In addition, the PBP environment300provides a basis on which a Profile specification that supports full PersonalJava facilities can be built. Hence, the PBP environment300is useful in devices where a basic graphical interface is required, but a full Abstract Window Toolkit (AWT) support, which is a standard API for providing graphical user interfaces (GUIs) in Java, is inappropriate. Thus, for example, the PBP environment300can be used for interactive digital television, Java-based automobile services, information kiosks, and other similar devices.

As shown inFIG. 3, the PBP stack300includes a Connected Device Configuration (CDC) layer302, a Foundation Profile (FP) layer304, and a PBP layer306. The CDC layer302provides a limited API and JVM for the PBP enabled device. Additional functionality, including security, is provided by the FP layer304. And finally, graphics functionality is provided in the PBP layer306.

As with other Java technologies, it is desirable to perform compatibility testing on the PBP layer306. However, a PBP layer306specification includes the definition of Xlets and their life cycles, which maybe implemented in a PBP implementation as an Xlet manager that manages the Xlets applications. Further, the definition generally does not include a public application manager API where the life cycle for the Xlets is defined. Hence, there is no way for the testing software to access the application manager in order to test the application manager's ability to manage the life cycle of an Xlet. Embodiments of the present invention address this issue using an Xlet manager testing interface, as shown inFIG. 4.

FIG. 4is a block diagram showing a local Xlet manager testing environment400, in accordance with an embodiment of the present invention. The Xlet manager testing environment400includes an Xlet manager254, which provides an environment for the Xlet programs256to execute. As mentioned above, the Xlet manager254, controls the state and execution of the Xlets256. AlthoughFIGS. 4–7will be described in terms of Xlets executing within an Xlet manager, it should be noted that the embodiments of the present invention can be used with any small program managed using an application manager, such as applets and an applet manager.

The Xlet manager testing environment400further includes an Xlet manager testing interface402, which provides a public API that allows testing software to test the Xlet manager's254ability to manage the life cycles of the Xlets256under its control. In this manner, a testing program can use the Xlet manager testing interface402to initiate prescribed application behavior in the implementation under test in order to test the results. For example, the Xlet manager testing interface402allows a test program to instruct the Xlet manager254to load an Xlet256dynamically at runtime. In addition, Xlet manager testing interface402allows a test program to request the Xlet manager254to change the state in the life cycle of an Xlet256, as shown inFIG. 5.

FIG. 5is a state diagram showing exemplary states500of a small application, such as an Xlet or applet. As shown inFIG. 5, a particular Xlet, at any given time, can be in a loaded state502, a paused state506, an active state504, or a destroyed state508. For example, when the Xlet manager first receives a request related to a particular Xlet, the Xlet manager may load the Xlet into memory, thus placing the Xlet into the loaded state502. Normally, from loaded state, the Xlet can enter paused state after it is initialized by the Xlet manager. Then from paused state, the Xlet can enter active state after it is started by the Xlet manager. When the Xlet is in the active state504, the Xlet is executing within the Xlet manager environment. In addition, Xlet manager may place the Xlet in a paused state506, wherein the execution of the Xlet is suspended. A paused Xlet can be started again, thus placing the Xlet back to the active state504. An Xlet may transition between the active state504and paused state506any number of times during the life cycle of the Xlet. In addition, an Xlet may move to a destroyed state508, wherein the Xlet has released all of its resources and terminated. An Xlet can move to the destroyed from any other state, as shown inFIG. 5.

Referring back toFIG. 4, the Xlet manager testing interface402further allows a test program to monitor the state of each Xlet256under the control of the Xlet manager254. Generally, the Xlet manager254tracks the state of each Xlet256under its control. The Xlet manager testing interface402allows a test program to query the Xlet manager254for the state of particular Xlets256. In this manner, embodiments of the present invention provide a mechanism for testing the life cycle of small programs designed to execute in conjunction with an application manager, such as applet managers and Xlet managers.

FIG. 6is a system diagram showing an Xlet life cycle testing system600, in accordance with an embodiment of the present invention. To test an application manager, it is often advantageous to utilize a separate computer to manage the test. Thus, the Xlet life cycle testing system600includes a testing computer202, which executes a test harness602. The test harness602controls the flow of the Xlet manager test, for example, by executing a test suite, obtaining test results, and storing the test results in appropriate directories.

During a test, an agent Xlet604is executed in the Xlet manager254under test. In addition, the agent Xlet604is placed in communication with the test harness604. In operation, the agent Xlet604receives test commands from the test harness602, and executes the test commands locally using the Xlet manager testing interface402. For example, to test the Xlet manager's ability to successfully load an Xlet, the test harness may include a test606that loads a test Xlet607from computer storage608. In this case, the test harness602sends a command to the agent Xlet604, which instructs the agent Xlet604to load and execute test606, which in turn loads the test Xlet607from the computer storage608. When test606starts executing, it sends a command to the Xlet manager254by calling a function defined in Xlet manager testing interface402, to load the test Xlet607.

Once the Xlet manager receives the load command from the Xlet manager254testing interface402, the Xlet manager254performs the load operation, and loads the test Xlet607. To test the Xlet manager's254ability to change the state of an Xlet, the test606further requests the Xlet manager254, for example, to destroy the Xlet607it just loads. To do that, test606can send a command, via the Xlet manager testing interface, to the Xlet manager254to destroy the test Xlet607. Upon receiving the destroy command from the Xlet manager testing interface402, the Xlet manager254calls the life cycle method for destroying an Xlet in test Xlet607and changes the state of the test Xlet607to a destroyed state. In addition, the test606can verify that the Xlet manager254correctly performs instructions by querying the state of Xlets using the Xlet manager testing interface402.

Thus, the Xlet manager testing interface402can be used during compatibility testing of application managers. As mentioned previously, compatibility testing refers to the methods used to test an implementation of a Java technology specification in order to assure consistency across multiple hardware platforms, operating systems, and other implementations of the same Java technology specification. When this assurance is accomplished by means of a formal process, application developers can be confident that an application will run in a consistent manner across all tested implementations of the same Java technology specification. In particular, embodiments of the present invention can be used to test a PBP implementation using a PBP technology compatibility kit (TCK) if the Xlet manager testing interface is implemented in the PBP implementation under test. In the present disclosure references to application manager testing interface refer to a testing interface for testing application managers for small programs. Hence, an application manager testing interface can be an Xlet manager testing interface, as described with reference toFIGS. 4 and 6, an applet manager testing interface for testing applet managers, or any similar type of program.

The PBP TCK is a portable, configurable and automated test suite for verifying the compliance of an implementation of a PBP Specification. Each application manager that actually controls the Xlet life cycle is implementation specific. The PBP TCK uses an agent Xlet and an Xlet manager testing interface to test an implementation's Xlet life cycle behavior for adherence to the specification. In this manner, the PBP TCK can programmatically communicate with the application manager of the device under test using the Xlet manager testing interface.

In one embodiment, the Xlet manager testing interface is specified by these two interfaces, namely, an XletManager.java interface and a ManageableXlet.java interface. The XletManager.java interface defines a mechanism for an application to introduce and load Xlets into the system, after which further life cycle control is handled by the implementation of the ManageableXlet interface. Once the system is aware of an Xlet, the ManageableXlet interface controls the life cycle of an Xlet by triggering state changes and querying for the state of an Xlet.

Following is a list of illustrated source files corresponding to the XletManager.Java interface and the ManageableXlet.java interface.

ManageableXlet.java:/** 1.1 @(#)ManageableXlet.java1.1**/package com.sun.tck.pbp.xlet;/*** This interface defines methods that trigger state changes* and query for the state of an xlet. The state change trigger* methods should be called from the same thread to guarantee* the correct sequence of state changes.*/public interface ManageableXlet {/*** Request the Xlet to enter PAUSED state from LOADED state.* It should be silently ignored if the Xlet is not in LOADED state at the* time of the request, otherwise the Xlet's initXlet( ) method should* be invoked.** Note that the state of the Xlet may not yet be changed when this method* returns, i.e., the method may return to the caller before completing* the work.**/public void initXlet( );/*** Request the Xlet to enter ACTIVE state from PAUSED state.* It should be silently ignored if the Xlet is not in PAUSED state at the* time of the request, otherwise the Xlet's startXlet( ) method should* be invoked.** Note that the state of the xlet may not yet be changed when this method* returns, i.e., the method may return to the caller before completing* the work.**/public void startXlet( );/*** Request the Xlet to enter PAUSED state from ACTIVE state.* It should be silently ignored if the Xlet is not in ACTIVE state at the* time of the request, otherwise the Xlet's pauseXlet( ) method should* be invoked.** Note that the state of the xlet may not yet be changed when this method* returns, i.e., the method may return to the caller before completing* the work.**/public void pauseXlet( );/*** Request the Xlet to enter DESTROYED state and invoke the Xlet's* destroyXlet(unconditional) method.** Note that the state of the xlet may not yet be changed when this method* returns, i.e., the method may return to the caller before completing* the work.**/public void destroyXlet(boolean unconditional);/*** Get the state of the xlet.** @return state of the Xlet, which should be one of* LOADED, ACTIVE, PAUSED, DESTROYED or UNKNOWN*/public int getState( );/*** Xlet is not loaded, or its state information* can not be found by the Xlet manager. This may happen* if the Xlet has been destroyed and the Xlet* manager does not keep its reference.*/public static final int UNKNOWN = 0;/*** Xlet is loaded by calling its* no-argument constructor.*/public static final int LOADED = 1;/*** Xlet is paused*/public static final int PAUSED = 2;/*** Xlet is active*/public static final int ACTIVE = 3;/*** Xlet is destroyed*/public static final int DESTROYED = 4;}

In the PBP TCK, Xlet manager testing is enabled by specifying the implementation class of Xlet manager testing interface as an argument to the agent Xlet using -xletManager option, followed by any other initialization arguments. For example, com.sun.tck.pbp.xlet.ri.XletManagerImp1 is the implementation class of Xlet manager testing interface for Sun's PBP reference implementation. In this case, it can be specified in the startup command line for the agent Xlet as follows (no other arguments are required by this implementation):
-xletManager com.sun.tck.pbp.xlet.ri.XletManagerImp1

For other PBP implementations, use the applicable implementation of the Xlet manager testing interface for startup instead of the com.sun.tck.pbp.xlet.ri.XletManagerImp1 class, followed by initialization arguments if any:
-xletManager implementation_class_name [arguments_if_any]

FIG. 7is a flowchart showing a method700for Xlet and applet manager testing, in accordance with an embodiment of the present invention. In an initial operation702, preprocess operations are performed. Preprocess operations can include implementing a specific application manager, developing small programs, such as Xlets to execute within the application manager, and other preprocess operations that will be apparent to those skilled in the art after a careful reading of the present disclosure.

In operation704, an Xlet manager testing interface specification is provided. As mentioned above, a typical implementation of an application manager program, such as a PBP Xlet manager, does not include a mechanism for external software to manipulate the life cycles of the Xlets under the application manager's control. Hence, the embodiments of the present invention address this issue by providing an Xlet manager testing interface specification for allowing external software to manipulate the life cycles of the Xlets under the application manager's control.

Then, in operation706, the Xlet manager testing interface is implemented. In one embodiment, the Xlet manager interface provides a standard public API usable by test software. Thus, a user can implement the Xlet manager interface API by incorporating the actual Xlet life cycle method and function calls of the particular application manager into the API implementation. In one embodiment, the developer of application manager of the implementation under test is expected to implement the Xlet manager testing interface API. Since the developer knows the internal architecture of their application manager, the developer has knowledge of the internal methods and functions of the application manager that control Xlet life cycle. Hence, to implement the Xlet manager testing interface, the developer incorporates this methods and functions into the Xlet manager testing interface API implementation.

Once the Xlet manager testing interface is implemented, a test harness and agent Xlet are executed, in operation708. As mentioned above, the test harness controls the flow of the Xlet manager test, for example, by executing a test suite, obtaining test results, and storing the test results in appropriate directories. The agent Xlet is executed using the Xlet manager to be tested. In addition, the agent Xlet is placed in communication with the test harness.

In operation710, the next test in the test suite is provided to the agent Xlet. As discussed previously, the agent Xlet receives test commands from the test harness, and executes the test commands locally by executing a test which uses the Xlet manager testing interface. For example, to test the Xlet manager's ability to successfully load an Xlet, the test suite may include a test that loads a test Xlet from computer storage. In this case, the test harness sends a command to the agent Xlet, which instructs the agent Xlet to load and execute the test that in turn loads the test Xlet, from the computer storage. To do that, the test sends a command to the Xlet manager via the Xlet manager testing interface, to load the test Xlet. Once the Xlet manager receives the load command from the Xlet manager testing interface, the Xlet manager performs the load operation, and loads the test Xlet.

As mentioned previously, the Xlet manager testing interface allows a test to load, change the state, and obtain the state status of Xlets under the Xlet manager's control. For example, the test can send a command, via the Xlet manager testing interface, to the Xlet manager to destroy the test Xlet just loaded. Upon receiving the destroy command from the Xlet manager testing interface, the Xlet manager changes the state of the test Xlet to a destroyed state. In addition, the test can verify that the Xlet manager correctly performs instructions by querying the state of Xlets using the Xlet manager testing interface.

A decision is then made as to whether additional tests remain, in operation714. If additional tests remain to be executed, the method700proceeds to another agent Xlet test load operation710. Otherwise, the method700completes in operation716, where post process operations are performed. Post process operations can include loading additional tests suites, terminating the agent Xlet, and other post process operations that will be apparent to those skilled in the art after a careful reading of the present disclosure.

Embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention may also be practiced in distributing computing environments where tasks are performed by remote processing devices that are linked through a network.