Open Test Framework
|
|
One of the most important benefit of OTX is the strict separation of test logic and runtime implementation. The so called “OTX Mapping” is a platform independent access to arbitrary external systems. It can be edited inside the graphical mapping editor. The mapping consists of 4 different parts, see picture below: First, the Screen-Mapping realize an access to controls inside a graphical user interface. The Device-Mapping can execute device services inside an arbitrary device driver like a native DLL and can return their results. The context and the state mapping reads information from or writes it to the environment.
The mapping binds OTX activities to existing external system at runtime. According to the element to be bound, this is called:
Binds a screen signature to an external screen, see AssemblyScreen.
Binds a device signature to a public method of a DotNet Assembly or a Web Service.
Binds a context variable to a public read only property of a DotNet Assembly.
Binds a status variable to a public write only property of a DotNet Assembly.
There are currently the following implementations for external systems.
Each implementation has special system requirements and can not be executed on every target system!
A proxy will be used if there is no real implementation or implementation by the user, see below. A proxy is an implementation without function.
When a procedure is executed which is used a proxy, all activities with access to external systems, e.g. OpenScreen or ExecuteDeviceService, perform a NOP (no operation).
An AssemblyScreen implementation is a DotNet class that is marked as a screen by special attributes, see table below. The attributes show the OTX Runtime which public methods, properties or events are used to open a screen or set a parameter. The screen can be implemented with an arbitrary complexity within the class, e.g. in WPF. In some cases, it may be useful not to create a screen, but to do something else, e.g. a database access.
The AssemblyScreen implementation supports the following OTX data types:
C# Code Sample (Sample PTX with including Visual Studio Project, see folder ./OTX-Mapping/Apps/OtxMappingSample/)
To see the complete example click here to fold.
In this case, the method indicated by the OpenScreen attribute can also return NULL.
The following table lists all supported attributes. The attributes are only a marker, that the mapping can find the right elements. You can create the attributes by yourself or you can use the file Attributes.cs inside the sample project above.
Attribute | Description |
---|---|
[OtxScreenSignature] | Class containing the screen. There can be several classes. |
[OtxScreenSignatureTermParameter] | Write property that sets the value of a ScreenSignatureTermParameter |
[OtxScreenSignatureInParameter] | Write property that sets the value of a ScreenSignatureInParameter |
[OtxScreenSignatureOutParameter] | Read property, which reads out the value of a ScreenSignatureOutParameter |
[OtxScreenSignatureInOutParameter] | Read and write property that reads or sets the value of a ScreenSignatureInOutParameter |
[OtxScreenIsOpen] | Reading property, which checks if the screen is open |
[OtxOpenScreen] | Method in which the screen is generated (returns a form object of this screen) |
[OtxCloseScreen] | Method in which closes the screen |
[OtxHighlightScreen] | Method in which the screen comes to the foreground |
[OtxScreenSignatureParameterValueChangedEvent] | Event that the OTX Runtime signals that a parameter has changed in the screen |
[OtxStructure] | Class describing an OTX structure |
[OtxStructureElement] | Read and write property within the class that describes an element of the structure |
[Description] | Optional description for display in the OTX Mapping Editor (from System.ComponentModel) |
A DotNet Assembly implementation is a DotNet class which public methods can be bound to a device service. A bound method can be called inside OTX via an ExecuteDeviceService activity. The called device service can be implemented with an arbitrary complexity within this class.
The DotNet Assembly implementation supports the following OTX data types:
C# Code Sample (Sample PTX with including Visual Studio Project, see folder ./OTX-Mapping/Apps/OtxMappingSample/)
To see the complete example click here to fold.
The web service implementation allows the author to call a web service from inside OTX. An example Web service for Euro conversion is http://webservices.gama-system.com/exchangerates.asmx. The services found in the web service are bound to a device service, which can be called via the ExecuteDeviceService activity.
The web service implementation supports the following OTX data types:
The user can also implement his own implementation via the event interface of the OTX Runtime API. Detailed information can be found in the OTX Runtime user documentation (DotNet/Java). If the activity is called within an OTX procedure, the OTX Runtime API fires the corresponding event. In the event processing function, the user can then implement his own implementation.
The event interface supports the following OTX data types:
Inside the OTX mapping editor all mapping links can be created and edited graphically as follows:
An external application can be stored in a central directory or within the project. This is a global OTF setting. All dependencies to an external application do not need to be added. But they must be exists in the same directory as the external application!
The left part lists valid elements found in the external application The right part lists the corresponding OTX elements.
Which elements matches is described above the list.
If a parent element is selected in the right part, a new OTX element can also be generated by clicking at the arrow.
Optionally specify the environment preset values to simulate a certain environment.
For all not already mapped Signature InOut- or Out-parameters as well as context variables a fixed value can be specified. These are values that are transported from the environment into the OTX procedure.