We use extensions in a lot of our test cases as well... however, we don't use them during record time. We add calls to the extensions via design time when creating the test code.
Truthfully, 99.9999% of the time, when you "record" a test, you're going to have to go back and make modifications anyways to a) improve timing, b) add loops and searches, c) parameterize data entry etc. You're going to be editing the test case anyways, so might as well shift the Record-time script extensions to design time.
Additionally, we've found that recording is good primarily for research... detecting what the general workflow is in a particular set of action, doing some initial namemapping,, etc. Recording a test case from beginning to end rarely works in more complicated applications so we don't really bother. Record chunks and segments, add them in, modify, lather, rinse, repeat.
While I'm with you that I don't generally like deprecation (for example, see my comment concerning the removal of the object checkpoint type), consider your own application under test. There are features, functions, bells, whistles, etc., that probably get added and removed all the time that your own end users don't like... and yet you still do it because the product roadmap you're aiming for requires the changes.
I can't speak for the decision processes at SmartBear. I don't like the object checkpoint depracation. But I have some useful workarounds that allow me to continue to function and still create tests the way I need to. So, while record time extensions are gone, design time still exists and that's where I find the most use anyways.
Robert, thanks for your interest.
All 1000 of my tests were recorded from beginning to end with little or no editing after recording. NONE of my record-time extensions can be replaced by design-time actions.
11 of the 14 extensions are custom checkpoints which obviously have to be invoked at run time.
Some of these have to call "helper APIs" to access and control 3rd-party widgets not fully supported by TC, such as the Developer Express TreeList object. In fact, this work-around of creating a helper API was given to me by SmartBear support because they said providing complete support would have been too much work.
One of my extensions re-implements the TC record feature we lost (IIRC) with Windows 8.x where TC no longer replaces file selector navigation and clicking the "Open" button with a single call to "dlgOpenLogFile OpenFile". That was another feature the TC documentation was quite proud of.
Without record-time support we're going to have to stick with v12.20. Eventually, as you can imagine, the product will stop working properly with new versions of Windows and we will lose the large investment we've made going down this road with TestComplete.
Perhaps if you show us an example of your script extensions, we can find another solution for you.
Marsha,
I don't think you'd be able to tell what I'm doing or especially why by looking at the code any better thant I can explain.
The extensions are mainly of two types:
1) convenience checkpoints
With 2 mouse clicks I create a custom checkpoint of all the widgets in a dialog. Edit widgets, radioButtons, checkBoxes, comboBoxes (both the selection and the entire list contents), tables, buttons. For all of these, sometimes I even capture the state (enabled/disabled) and the label caption if it's one that changes dynamically (EG a button might say "Create" or "Update" depending on the program state). Note that sometimes I call an API that gives the entire contents of a table, not just what is in the visible rows at the time.
2) unsupported widgets
Developer Express, compiled by C++Builder, is not fully supported and my request to enhance it was denied almost 6 years ago. We had to add an API to our program that I call from record-time extensions that set or ask for the state and contents of widgets that TC cannot see individually. The code added to the Keyword Test by the runtime extension calls the API and both sets values and gets values for these widgets to compare with what was previously recorded.
Both of the above must be done at record time to capture the state at the moment. Stopping the recording and calling extensions that generate code that is added to the Keyword Test might work, if it's even supported which I don't know, but I do know from experience that the disruption to one's train of thought of starting and stopping recording is unbearable during a complicated or long scenario.
Does this give you any ideas?
From September, 2011:
Hi Rick, We have investigated the problem and found that we cannot resolve it in a reasonable period of time as it requires too significant changes to the debug information reading functionality. The problem concerns only applications compiled with C++Builder. So, unfortunately, both the Expand action and the Table checkpoint will not work for this control in your case and you will have to work with the control without using this functionality. The most convenient solution I see at the moment is to ask the application developers to implement a helper class within the tested application that will perform needed actions with the tree list control. This class should have methods that will expand the specific needed node and get a value of the specified cell of the control. You can create an instance of this object and assign it to a public property of the application main form. Get the instance of the object from your TestComplete test using this property and call its methods passing a reference to the tree list controls and the needed parameters. Best regards, David
Hi rickm
Just an fyi, most of us here don't work for Smartbear and have all probably hit a wall with something that's been changed or taken away or not fixed like we'd like. We're happy to help if we can.
for this:
Both of the above must be done at record time to capture the state at the moment. Stopping the recording and calling extensions that generate code that is added to the Keyword Test might work, if it's even supported which I don't know, but I do know from experience that the disruption to one's train of thought of starting and stopping recording is unbearable during a complicated or long scenario.
I see a couple of choices here.
One is the one you said you don't want to do, which is starting and stopping a recording. If you did want to try it, you can stop where the checkpoint belongs, add it manually, then use Append to go on in your scenario.
A way without stopping would be to just click somewhere off to the side or do some other neutral action to make a place holder for your checkpoint, then continue with the rest of the test. When you've finished recording, then you can go back and swap the place holder for the checkpoint manually.
