cancel
Showing results for 
Search instead for 
Did you mean: 

Lockable Mapped Objects

0 Kudos

Lockable Mapped Objects

A way I try to cut out duplicate mapped objects, like navigation links, is by having a parent page object wherein the URL consists of only the official name of the site capped with *s. I map all of my navication links to this page. However, when recording, Test complete will map every object under this one page object.

 

Therefore, it would be nice if there was an objtion to set this object to be locked. Namely, the object is set so that children can only be added to it manually and not automatically. 

3 Comments
Community Hero

You can tell TestComplete to just not map automatically on recording.   Under Tools | Options | Engines | NameMapping turn off the "Map object names automatically".  This does not prevent you from manually mapping it just means that ALL mapping is manual.  To be honest, I prefer that because it means I have more control over what gets mapped and how rather than letting TestComplete decide.

New Contributor


@tristaanogre The goal with the lockable feature is to make it so TC still mapps objects under those page objects that are not locked while overlooking the locked ones. Our application is very large, so to have to manually map every object would undermine the time saving potential of recording. I would like to see Test Complete's recording abilities become more reliable/useful so that we can be sure to reach our automation goals within our time goals. 

 

Perhaps I am not recognizing the true intended usefullnessof the recording tool. It appears to me that manual name mapping would undermine its usefullness. If not to map and create tests, what is the recording feature usefull for? I could see how it might be usefull after everything has already been mapped manually, but in large applications it would be a trumendous task. 

Community Hero

Here's the deal:  recording is good in limited ways.  It allows you to record stuff for automation quickly for rapid turnaroun. Recording is BAD for persisting long term test cases because you will inevitably have timing issues, object recognition issues, etc., that you will need to manually adjust for anyways.
In my experience using TestComplete (and, in fact, with any record/playback automation tool), you'll almost ALWAYS go back and edit what you recorded.  For TestComplete, this means both NameMapping as well as test code/steps.  Automatic NameMapping doesn't always take into consideration properties that may be dynamic.  Also, it only keeps things unique so long as there's not something else similar. For example, when working with a web application, I've had it record an HTML table object as just simply by the ObjectType of "Table" when there are other tables sharing the same level in the tree.  This causes some issues down the road.

 

What I use recording for is for discovery:

 

1) How does TestComplete interpret the user actions?

2) What components need to be mapped?

3) What is the logical flow of the test steps as interpreted by code?

 

From there, I almost ALWAYS go back and make edits.  Edits would consist of but aren't necessarily limited to.

 

1) Correcting mapping criteria to account for dynamic values and more accurate unique property/value pairs

2) Adjusting automation timing to account for page loads, dynamically created objects, etc

3) Adding loops like for and while to make the automation more efficient

4) Adding if/then logic for object identification and verification for workflow (if an object doesn't exist when I want it to, throw exception and error out gracefully)