Patent Application
20060179350
The detailed description refers to the following drawings.
Dynamic marshaling testing is described herein.
Client device 105 may be at least one of a variety of conventional computing devices, including a desktop personal computer (PC), workstation, mainframe computer, Internet appliance, set-top box, and gaming console. Further, client device 105 may be at least one of any device that is capable of being associated with network 125 by a wired and/or wireless link, including a personal digital assistant (PDA), laptop computer, cellular telephone, etc. Further still, client device 105 may represent the client devices described above in various quantities and/or combinations thereof. “Other” device 115 may also be embodied by any of the above examples of client device 105.
Server device 110 may provide any of a variety of data and/or functionality to client device 105 or “other” device 115. The data may be publicly available or alternatively restricted, e.g., restricted to only certain users or only if an appropriate subscription or licensing fee is paid. Server device 110 may be at least one of a network server, an application server, a web blade server, or any combination thereof. Typically, server device 110 is any device that is the source of content, and client device 105 is any device that receives such content either via network 125 or in an off-line manner. However, according to the example implementations described herein, client device 105 and server device 110 may interchangeably be a sending host or a receiving host. “Other” device 115 may also be embodied by any of the above examples of server device 110.
“Other” device 115 may further be any device that is capable of implementing dynamic marshaling testing 120 according to one or more of the example implementations described herein. That is, “other” device 115 may be any software-enabled computing or processing device that is capable of implementing dynamic marshaling testing for an application, program, function, or other assemblage of programmable and executable code, across an interface between a managed execution environment and an unmanaged execution environment. Thus, “other” device 115 may be a computing or processing device having at least one of an operating system, an interpreter, converter, compiler, or runtime execution environment implemented thereon. These examples are not intended to be limiting in any way, and therefore should not be construed in that manner.
Network 125 may represent any of a variety of conventional network topologies, which may include any wired and/or wireless network. Network 125 may further utilize any of a variety of conventional network protocols, including public and/or proprietary protocols. For example, network 125 may include the Internet, an intranet, or at least portions of one or more local area networks (LANs).
Data source 130 represents any one of a variety of conventional computing devices, including a desktop personal computer (PC), that is capable of generating 135 code for an application, program, function, or other assemblage of programmable and executable code, any of which is capable of being tested in accordance with various implementations of dynamic marshaling testing 120. Alternatively, data source 130 may also be any one of a workstation, mainframe computer, Internet appliance, set-top box, gaming console, personal digital assistant (PDA), laptop computer, cellular telephone, etc., that is capable of transmitting at least a portion of an application, program, or function to another work station. Further, code, which may or may not be object-oriented code, from data source 130 may be transmitted from data source 130 to any of devices 105, 110, and 115 as part of an on-line notification via network 125 or as part of an off-line notification.
Interface 205 may refer to the interoperability between execution environment A 210 and execution environment B 215. That is, interface 205 may refer to the ability of data to be marshaled between execution environment A 210 and execution environment B 215, in either direction, in such a manner that the data is readable and executable, as intended, in the different execution environment.
Examples of managed execution environment A 210 may include: Visual Basic runtime execution environment; Java® Virtual Machine runtime execution environment that is used to run, e.g., Java® routines; or Common Language Runtime (CLR) to compile, e.g., Microsoft .NET™ applications into machine language before executing a calling routine.
Managed execution environments may provide routines for application programs to perform properly in an operating system because application programs require another software system in order to execute. Thus, an application program may call one or more managed execution environment routines, which may reside between the application program and the operating system, and the runtime execution environment routines may call the appropriate operating system routines.
Managed execution environments have been developed to enhance the reliability of software execution on a growing range of processing devices including servers, desktop computers, laptop computers, and a host of mobile processing devices. Managed execution environments may provide a layer of abstraction and services to an application program running on a processing device, and further provide such an application program with capabilities including error handling and automatic memory management.
Accordingly, unmanaged execution environment 215 may refer to application programs as they are viewed by an operating system. That is, unmanaged execution environment 215 may refer to an application program outside of managed execution environment 210.
Further, in the following description of marshaler 300, various operations will be described as being performed by components including test data manager 305, test generator 310, test verifier 315, and test analyzer 320. The various operations that are described with respect to a particular one of the aforementioned components may be carried out by the particular component itself, or by the component in cooperation with one or more of the other components. Further, the operations of the components 305, 310, 315, and 320 may be implemented as hardware, firmware, or some combination thereof.
Test data manager 305 may capture and store test information, particularly information pertaining to a testing scenario for which interface 205 (see
The test information (i.e., parameters) for testing interface 205 may be randomly set for each test case. That is, in order to test interface 205, multiple permutations of testing parameters may be assembled by marshaler 300 as a matrix of testing parameters is captured and stored by manager 305. For each of the test cases (i.e., assemblies), the parameters may be randomly set.
The parameters may or may not be particular for a marshaling direction (i.e., either managed execution environment A 210-to-unmanaged execution environment B 215; or vice-versa). It is noted that the parameters described below are described utilizing sample nomenclature that may be changed or modified, and such nomenclature is not intended to be limiting in any manner. Non-limiting examples of such parameters indicate:
Furthermore, when a data type is an array, more parameters are possible, non-limiting examples of which include:
Further still, when a data type is one of a class, enumeration, structure, interface, or delegate, more parameters are possible. Non-limiting examples of such further parameters include:
Test generator 310 may utilize the test information captured and stored by manager 305 to dynamically generate test cases (i.e., assemblies) for testing interface 205 between execution environment A 210 and execution environment B 215. Further, such dynamic test case generation may be recursive in nature. For instance, at least one of the parameters described above may be a delegate having corresponding parameters itself; at least one of the further parameters may be a structure having several fields; and one of such fields may be a delegate.
Test generator 310 may utilize known dynamic code generating implementations for either of a managed execution environment or an unmanaged execution environment depending, obviously, upon the direction of the dynamic marshaling testing. An example of such dynamic code generating in managed execution environment A 210 (
As part of dynamically generating the test cases based on the test matrix captured and stored by manager 305, test generator 310 may further generate one or more callback methods to be utilized in testing interface 205 (
The method description callback method may be provided to indicate, to a target of a corresponding test case, a number of arguments included in the test case, a stack size required for the test case, and a calling convention for the test case. Alternative examples of the method description callback method may be utilized to indicate further information regarding the parameters of the test case. Regardless, the method description callback method may provide at least the parameters necessary for a target object in the different execution environment to simulate the scenario for the particular test case.
The method implementation callback method may be provided to indicate a native view of the stack in the different execution environment, in accordance with a particular one of the generated test cases. That is, the method implementation callback method may enable a target object in the different execution environment to enable verification that marshaling of a particular test case was executed correctly.
Further, the method implementation callback method may include code to enable the generated test case to check (i.e., verify) a return value from the target object in the different execution environment and, thus, perform error checking. Even further, the method implementation callback method may include data to indicate a particular technique required to implement the aforementioned verification and error checking. That is, since method invocation and processor state may be handled differently for different processor architectures, the method implementation callback method may include instructions for receiving the return value from the target object in the different execution environment. A non-limiting example of such instructions may include shifting the stack and stack registers by appropriate amounts to enable the reading of specific register information or locations on a current stack in the different execution environment.
Test verifier 315 may utilize a value returned by the method implementation callback method to verify that marshaling for the generated test case has been correctly executed. Thus, according to at least one example implementation, test verifier 315 may be a dll (dynamic link library) to check a value returned from a target object in the different execution environment against an expected value specified in the test matrix captured and stored by test data manager 305. By checking the “value,” the verifier may verify that the state and data associated with the method meet expectations, accomplished by checking return values of the method implementation callback method, values of by-reference parameters, and ensuring that no exceptions are thrown. These implementations for verifying are provided as examples only, and should not be construed to be limiting in any manner.
Test analyzer 320 may be provided by at least one example implementation of marshaler 300 to provide a readable deconstruction of the generated test case, typically in the form of an XML file. Accordingly, test analyzer 320 may lay out, for inspection and/or analysis, information regarding the test case including, but not limited to: scenario type, parameters (including the number of parameters and respective types), return type, and attributes.
Target object 400 may be a universal COM (UCO) object that is capable of mimicking any COM (component object model) or dll native to different execution environment B 215 (
Typically, COM objects may be called by binding to a virtual function table (i.e., vtable) slot on a COM interface. To mimic any COM interface, UCO 400 returns a COM interface having vtable 405, of which slots 0, 1, and 2, may reference methods of IUnknown. IUnknown is understood to be common for COM objects, and comprise QueryInterface 410, AddRef 415, and Release 420.
The remaining slots of vtable 405 reference a static export that may be referred to as the UniversalMethod 425, which enables UCO 400 to expose COM interfaces or static dll exports. vtable 405 is shown as having multiple slots, the number of which is specified by the parameters of the test case, that call instances of UniversalMethod 425′.
UniversalMethod 425 may be regarded as a static export that typically has the same name (i.e., UniversalMethod) and a same ordinal. However, a corresponding signature may differ for one COM object to another. Accordingly, the execution environment for marshaler 300 (
Block 505 may represent the capture and store of test information by test data manager 305 of marshaler 300.
Block 510 may represent the random generation of at least one test case by test generator 310. More particularly, the captured test information may be used to dynamically generate test cases (i.e., assemblies) for testing interoperability between two different execution environments. The test case may be generated using known dynamic code generating implementations for either of a managed execution environment or an unmanaged execution environment depending upon the direction of the dynamic marshaling testing as specified in the captured test information.
Further, included in the test case are one or more generated callback methods. The first callback method may provide a COM object 400 with information regarding the parameters of the test case. The second callback method may provide a view of the stack from the perspective of the different execution environment.
Block 515 may refer to the dynamically generated test case being executed by marshaler 300, typically via test generator 310, to COM object 400 in unmanaged execution environment B 215.
Block 520 may refer to return values being received by marshaler 300, typically by test verifier 315. The return values may include a native view of the stack in unmanaged execution environment B 215.
More specifically, in order to return a value in the appropriate state, UniversalMethod 425 on COM object 400 receives, at least, the number of arguments being passed thereto by the test case, the stack size required by the test case, and the calling convention of the test case. Such parameters are indicated by the method description callback method. To plug in an arbitrary implementation into a simulated method in unmanaged execution environment B 215, UniversalMethod 425 utilizes the method implementation callback method to provide the test case with a view of the unmanaged stack.
Block 525 may refer to test verifier 315 checking the returned value against an expected value specified in the test matrix captured and stored by test data manager 305.
Block 530 may refer to test analyzer 320 analyzing the test information by providing a readable deconstruction of the generated test case, typically in the form of an XML file. Thus, information regarding the test case including, but not limited to: scenario type, parameters (including the number of parameters and respective types), return type, and attributes, may be laid out for analysis and/or inspection.
Accordingly, an interoperability between different execution environments may be dynamically tested.
Various modules and techniques may be described herein in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. for performing particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
An implementation of these modules and techniques may be stored on or transmitted across some form of computer readable media. Computer readable media can be any available media that can be accessed by a computer. By way of example, and not limitation, computer readable media may comprise “computer storage media” and “communications media.”
“Computer storage media” includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer.
“Communication media” typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as carrier wave or other transport mechanism. Communication media also includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. As a non-limiting example only, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above are also included within the scope of computer readable media.
Reference has been made throughout this specification to “one embodiment,” “an embodiment,” or “an example embodiment” meaning that a particular described feature, structure, or characteristic is included in at least one embodiment of the present invention. Thus, usage of such phrases may refer to more than just one embodiment. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
One skilled in the relevant art may recognize, however, that the invention may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to avoid obscuring aspects of the invention.
While example embodiments and applications of the present invention have been illustrated and described, it is to be understood that the invention is not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems of the present invention disclosed herein without departing from the scope of the claimed invention.
