ODT disappeared in version "10.40"
TestComplet upgraded to the lasted version, but the ODT is not present... I need help, someone could help me how to solve this? alread seen in the Extensions folder, the archives "tcODT....
Forum Discussion
We, too, want to KEEP ON USING ODT.
Maybe, it's "rarely used", because, maybe, it is not the simplest Approach. But, if You know how to apply it, it is much better than spaghetti Scripting.
Here is, how I use it:
Normal procedural test scripts tend to have a poor, spaghetti-like structure. There are long routines, and at a given code location it is not clear, which test step and/or test case is implemented there. Test data and reference data are often defined in the code as magic numbers and strings.
Using ODT, I can do it better: the “script” is clearly divided into sections (Abschnitte), sequences and steps (Testschritte), see the attached screenshot of ODT data with the structure highlighted in green.
Please notice the green rectangle: item0 and item1 hold test case references to the test step. This is a perfect way to integrate metadata. I could easily add a script to evaluate them, e.g. to generate a table or list containing each step and its implemented test cases. In a standard test script, I’d have to use code patterns to integrate metadata and I’d have to do code analysis to evaluate, which is far less comfortable and maintainable.
The test steps could have names, but I’ve left that out, so they are only identified via their sequence and hierarchical position – like it was in my original test script for manual testing. However, each test step calls an ODT test function, which I gave a name to like Test_2_1_2(), containing the original test step ID.
So, for each ODT test script code location, it is clear a) which test step it serves for (from the routine name) and b) which test cases are implemented.
In addition, It is perfectly easy to add setup and shutdown functionality on each level of the test object hierarchy, and it leads to transparent results.
To separate test and reference data form the scripts, I use the StdDatum data elements (highlighted in blue) integrated in the Daten_Test and Daten_Ref arrays of test elements on every level of hierarchy. The upper example shows a dialog that is to be opened by menu “Einrichten|BDE-Recorder”. In the lower example, a date value is to be set for field “Auflösung”.
Accessing the ODT data tree originally is not so very comfortable, You have to deal with all these .owner, .properties and .value elements. So, to facilitate using my data definitions, I use a function defined in a script extension to get hold of the test data. Calling “Td = PVA_0.ODT.TestDatenArr(This, 0)” in an ODT test routine gives me an array with a wrapper object for each StdDatum in the Daten_Test property of This object. Calling “TdP = PVA_0.ODT.TestDatenArr(This, 1)” does the same for the superordinate test data object, and so on.
The wrapper for StdDatum is a vbs object. It contains mostly getters/setters for the properties and also some very convenient procedures to use in ODT test procedure.
If I call “TdP(mcBdeTblDlgIx).DialogOpenByMenu” from the ODT test routine of step item1 , I access the dialog in the upper example. TdP(mcBdeTblDlgIx) gives me access to the test data element with the given index on parent-level. During initialisation, TC took the alias string from field ObjektDefinition and created an alias object from it and stored it into field “object”. Now, the DialogOpenByMenu routine opens the dialog per menu and waits until the alias object is ready (exists and visible) and creates and stores a wrapper object for the dialog into the Objekt field – ready to use.
Calling “Td(mcSchrAufloesungIx).SetText(myFrm)” sets in the lower example the text from the StdDatum property “Wert” to the field with caption “Auflösung”. The parameter myFrm holds a wrapper object for the frame carrying the target field, I get it from the wrapper object of the dialog.
So as a result – opening a dialog or setting a value can easily be defined in the data tree and executed in a ODT test function by a simple line of code. The test and reference data are located in the data tree, separated from the test script code. There they can be moved to the appropriate level in the test element hierarchy with little effort (copy & paste), the adaptions in the ODT code can easily be handled, if constants are used as index in the test data array (Td).
Furthermore, ODT is very useful to hold and evaluate metadata and for disposition of setup/shutdown functionality.
Regards,
Manfre
Maybe, it's "rarely used", because, maybe, it is not the simplest Approach. But, if You know how to apply it, it is much better than spaghetti Scripting.
Here is, how I use it:
Normal procedural test scripts tend to have a poor, spaghetti-like structure. There are long routines, and at a given code location it is not clear, which test step and/or test case is implemented there. Test data and reference data are often defined in the code as magic numbers and strings.
Using ODT, I can do it better: the “script” is clearly divided into sections (Abschnitte), sequences and steps (Testschritte), see the attached screenshot of ODT data with the structure highlighted in green.
Please notice the green rectangle: item0 and item1 hold test case references to the test step. This is a perfect way to integrate metadata. I could easily add a script to evaluate them, e.g. to generate a table or list containing each step and its implemented test cases. In a standard test script, I’d have to use code patterns to integrate metadata and I’d have to do code analysis to evaluate, which is far less comfortable and maintainable.
The test steps could have names, but I’ve left that out, so they are only identified via their sequence and hierarchical position – like it was in my original test script for manual testing. However, each test step calls an ODT test function, which I gave a name to like Test_2_1_2(), containing the original test step ID.
So, for each ODT test script code location, it is clear a) which test step it serves for (from the routine name) and b) which test cases are implemented.
In addition, It is perfectly easy to add setup and shutdown functionality on each level of the test object hierarchy, and it leads to transparent results.
To separate test and reference data form the scripts, I use the StdDatum data elements (highlighted in blue) integrated in the Daten_Test and Daten_Ref arrays of test elements on every level of hierarchy. The upper example shows a dialog that is to be opened by menu “Einrichten|BDE-Recorder”. In the lower example, a date value is to be set for field “Auflösung”.
Accessing the ODT data tree originally is not so very comfortable, You have to deal with all these .owner, .properties and .value elements. So, to facilitate using my data definitions, I use a function defined in a script extension to get hold of the test data. Calling “Td = PVA_0.ODT.TestDatenArr(This, 0)” in an ODT test routine gives me an array with a wrapper object for each StdDatum in the Daten_Test property of This object. Calling “TdP = PVA_0.ODT.TestDatenArr(This, 1)” does the same for the superordinate test data object, and so on.
The wrapper for StdDatum is a vbs object. It contains mostly getters/setters for the properties and also some very convenient procedures to use in ODT test procedure.
If I call “TdP(mcBdeTblDlgIx).DialogOpenByMenu” from the ODT test routine of step item1 , I access the dialog in the upper example. TdP(mcBdeTblDlgIx) gives me access to the test data element with the given index on parent-level. During initialisation, TC took the alias string from field ObjektDefinition and created an alias object from it and stored it into field “object”. Now, the DialogOpenByMenu routine opens the dialog per menu and waits until the alias object is ready (exists and visible) and creates and stores a wrapper object for the dialog into the Objekt field – ready to use.
Calling “Td(mcSchrAufloesungIx).SetText(myFrm)” sets in the lower example the text from the StdDatum property “Wert” to the field with caption “Auflösung”. The parameter myFrm holds a wrapper object for the frame carrying the target field, I get it from the wrapper object of the dialog.
So as a result – opening a dialog or setting a value can easily be defined in the data tree and executed in a ODT test function by a simple line of code. The test and reference data are located in the data tree, separated from the test script code. There they can be moved to the appropriate level in the test element hierarchy with little effort (copy & paste), the adaptions in the ODT code can easily be handled, if constants are used as index in the test data array (Td).
Furthermore, ODT is very useful to hold and evaluate metadata and for disposition of setup/shutdown functionality.
Regards,
Manfre
