Browse Prior Art Database

Automated JPOS/ OPOS Testing Architecture

IP.com Disclosure Number: IPCOM000014508D
Original Publication Date: 2000-Dec-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 50K

Publishing Venue

IBM

Abstract

Disclosed is a an architecture for the automated JPOS/ OPOS testing. Functional testing of IBM Service Objects (SO) for OLE for Retail POS (OPOS) has always been a long drawn manual process. Applications developed using Visual Basic are used to test each of the eleven devices that IBM SO supports. The user must interact with the test tool to exercise the various APIs of the device under test and inspect the result of the execution. Some of the test cases are pretty standard in the sense that they could be executed without the need for human intervention. The end result of the execution is compared with a pre-specified expected result and the detail of the execution would be captured in a log file. The novel architecture below (see Fig. 1) describes how we could automate the functional testing process such that minimal human intervention is required. In addition to minimizing human intervention, we have created an environment such that we could test both Java for Retail POS (JPOS) and OPOS with a flag that we pass into the test environment. The automation tool reduces the testing effort and make testing more efficient, effort-less and most importantly, repeatable. The architecture makes use of JACL (the Java implementation of Tcl/Tk) to interpret the Tcl scripts. The Tcl scripts contain the APIs that we want to test the POS Subsystem with. Testing of JPOS is pretty straight forward because primarily JACL is a Java implementation of Tcl/Tk and it integrates seamlessly with JPOS. It is treated like an application that calls the POS Subsystem. The biggest challenge is to enable JACL to talk to OPOS objects. This is essentially trying to link Java with Microsoft COM objects. There are numerous Java-COM bridges in the market but none of them is able to interface the JACL application to the OPOS COM Automation objects smoothly. The most straight forward implementation for Java-COM bridge would be to make use of Microsoft Visual J++ and Microsoft's implementation of JVM. However, that would mean extremely tight coupling with Microsoft's products and the bridge cannot be executed on Sun's or IBM's JDK. With that in mind, we have adopted a third party application called the Jacob Project (http://users.rcn.com/danadler/jacob). The initial release of Jacob Project does not support the Free-Threading Model (in essence multithreading support). Without Free-Threading support, the COM events delivered to Java through Connection Points were blocking. This means that the client application (in this case JACL) is not able to receive OPOS triggered events. This serious limitation prevented us from deploying the product in our test environment.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Automated JPOS/ OPOS Testing Architecture

Disclosed is a an architecture for the automated JPOS/ OPOS testing. Functional testing of IBM Service Objects (SO) for OLE for Retail POS (OPOS) has always been a long drawn manual process. Applications developed using Visual Basic are used to test each of the eleven devices that IBM SO supports. The user must interact with the test tool to exercise the various APIs of the device under test and inspect the result of the execution. Some of the test cases are pretty standard in the sense that they could be executed without the need for human intervention. The end result of the execution is compared with a pre-specified expected result and the detail of the execution would be captured in a log file. The novel architecture below (see Fig. 1) describes how we could automate the functional testing process such that minimal human intervention is required. In addition to minimizing human intervention, we have created an environment such that we could test both Java for Retail POS (JPOS) and OPOS with a flag that we pass into the test environment. The automation tool reduces the testing effort and make testing more efficient, effort-less and most importantly, repeatable.

The architecture makes use of JACL (the Java implementation of Tcl/Tk) to interpret the Tcl scripts. The Tcl scripts contain the APIs that we want to test the POS Subsystem with. Testing of JPOS is pretty straight forward because primarily JACL is a Java implementation of Tcl/Tk and it integrates seamlessly with JPOS. It is treated like an application that calls the POS Subsystem.

The biggest challenge is to enable JACL to talk to OPOS objects. This is essentially trying to link Java with Microsoft COM objects. There are numerous Java-COM bridges in the market but none of them is able to interface the JACL application to the OPOS COM Automation objects smoothly. The most straight forward implem...