Why no Object repository in TestComplete
I'm a new user to TestComplete. Biggest surprise to me coming from using other test automation tools is the complete lack of the separate Object repository concept in Test complete. Separation of the...
Forum Discussion
Actually, yes you can add items to NameMapping by a click of a button... there is an item in the tool bar that allows you to select an object on screen and add it to your NameMapping. From the object browser, you can also right click on any object and add to NameMapping. When recording, Test Complete can automatically add items.
With NameMapping, if the GUI changes, you adjust your mapping without having to change your code. For that matter, there is the Aliases layer which separates the mapping from what you actually use in your code so, if your hierarchy of components, properties, etc changes, you can adjust how an object is mapped while keeping the same alias structure.
While you may not be able to drag and drop into your code (a cool idea, btw, worth suggesting in the feature requests part of this community) both in keyword tests and script code, TestComplete has what amount to an intellisense to the Aliases that makes writing the code easy.
While NameMapping is not the same as UFT's object repository, it has a lot of power. And I can attest in my current project that, when used well, it can actually speed up test development. We recently upgraded the code for one project to another and all i had to do for the GUI changes was adjust a couple of mapped properties and all my tests ran with no code changes at all.
Given your calling it an "Object Repository", I assume you're coming from a QTPro/UFT background?
I was the same.
The Name Mapping in TestComplete is a little different to the Object Repo in QTPro/UFT, but is used in much the same way. What I will say, as you are new to it and this will save you headaches further down the line, is make sure you understand the difference between the full Name Map and the Alias Map.
If your Alias Map is a straight copy of your Name Map, you're doing it wrong. The Alias Map should be a subset of the Name Map. And it should cut out the parts of the application you aren't really interested in (usually series of container panels and frames used to build the page structure). Aliases should also be renamed to be as humanly readable as possible.
So your full Name Map will be a large, technical looking, map of the ENTIRE application. It will have LOTS of layers, be tricky to read unless you do a LOT of renaming, and will be big - as it will contain EVERYTHING. (It has to)
But your Alias Map should be much more readable, smaller, and more like a representation of the application as the user sees it, without all the irrelevant container object they don't care about.
Once you get this worked out and set up properly, it makes using Aliases in you code much more pleasant. It also makes changes to application structure much more manageable. If a few containers change, but the buttons at the end of it do, simply correct the name map and the Alias will continue to work just as it always did. If you find yourself having to update both as a result of container change, in my opinion, your setup is wrong.
You can also use multiple copies of a single Name Map item in the Alias Map, renamed so they "look" different. I commonly do this with container frames which, as far as the user is concerned, are distinct and different panels, but in the background, they actually aren't. But it makes more sense in the Alias Map if they look that way.
And to add to what tristaanogre has already said, yes you can map items using a tool in TC. But, as with QTPro/UFT, expect to have to pay a bit a bit of attention to the properties used and make manual modifications where required if you want things to be reliable long term. It's seldom 100% reliable to use automatic identification properties all the time.
Thanks a lot. That is a sensible way to manage the objects. Is this described in the documentation in some way ? From the Inital look, it doesn't seem to be obvious.
I will get back after checking the option to add objects automatically, but what can really improve things is a tool which can capture all the objects of the application with its own default properties (which we can define) for each class by the click of a button. Once it captures, we can rename them and edit the properties and so on.
And BTW, is there a way to share the Name map like saving it as a separate file and include in multiple projects etc. ?
There are various options for configuring and using automatic mapping/capture. But I don't really use them. I've been stung by automatic mapping often enough over the years that I just prefer to do it manually now. Takes a little longer up front obviously, but at least I know my references should be rock solid so pays off down the line.
And you should find everything you need to know starting from here: https://support.smartbear.com/testcomplete/docs/testing-with/object-identification/name-mapping/overview.html
** EDIT **
tristaanogre .... lol .... Snap! :smileylol:
abinash11 wrote:
Thanks a lot. That is a sensible way to manage the objects. Is this described in the documentation in some way ? From the Inital look, it doesn't seem to be obvious.
abinash11 wrote:
I will get back after checking the option to add objects automatically, but what can really improve things is a tool which can capture all the objects of the application with its own default properties (which we can define) for each class by the click of a button. Once it captures, we can rename them and edit the properties and so on.
There's not currently a tool to map the entire application up front. TestComplete interacts with the running application to get the objects and their properties so, if the application isn't running, you can't map something. Likewise, if the object isn't currently instantiated in the application, you can't map it. Considering that in many modern applications, there are a lot of objects that are dynamically generated, mapping everything up front will still require some manual process. However, once an item is mapped, you can then select the option to map child objects en masse (right click on the mapped item in NameMapping and select the appropriate context menu).
As for appling default properties, there's the concept of NameMapping Templates. I haven't used them very much but I'm considering them for the current project I'm on. Check it out at https://support.smartbear.com/testcomplete/docs/testing-with/object-identification/name-mapping/templates/index.html. In the exploration I've done with this, this works VERY well in making the mapping simpler.
abinash11 wrote:
And BTW, is there a way to share the Name map like saving it as a separate file and include in multiple projects etc. ?
Yup. Same way you share script code or keyword tests. However, one NameMapping file per project. Basically, when you create a new project, make sure it doesn't create it with the NameMapping file already created (or, if it does, just remove it). Then, right click on the project, select "Add -> Existing Item", browse to your NameMapping file and select it.
One additional note:
We do use NameMapping a lot for identifying most of our components and functionality in our application. However, there are some instances where we choose not to explicitly map an object. For example, we have a table in our application that has rows of data records. Those rows have clickable controls in different cells. The number of rows is variable, and even individual data records drop out or are added in dynamically as the application is run. So, mapping a control in Cell(1,2) in the table and expecting it to correspond to the information we need at run time is unwise. So, for these kinds of situations, we map the parent control (the table) and then use features like FindChild, FindAllChildren, etc., to find the dynamic controls that we need for our test. This is just one example but there are others depending upon the controls, the application under test, etc. There will be, at some point, a need to do code-based object recognition. What I would recommend for those situations is create libraries of methods to do the work for you for the specific controls and situations you need. Pass Alias objects into those methods and let them operate on the object to find and interact with the specific controls.Thanks a lot for the detailed reply.
TestComplete interacts with the running application to get the objects and their properties so, if the application isn't running, you can't map something. Likewise, if the object isn't currently instantiated in the application, you can't map it.
I'm talking about a running application. I should have made it clear that capturing all the objects mean that with a click of a button, you can capture all the objects on a particular screen on the application that is running. UFT has this concept of 'Navigate and Learn' which can do this. I have an application with 70 screens and more than 4000 objects. Doing it the UFT way will save huge amount of time.
Considering that in many modern applications, there are a lot of objects that are dynamically generated, mapping everything up front will still require some manual process.
Of course it does. But starting from something with 90% work done is so much better than starting from scratch.
However, once an item is mapped, you can then select the option to map child objects en masse (right click on the mapped item in NameMapping and select the appropriate context menu).
This is better. I will try this and get back.
