Also, you should make better use of the Alias map.
The name map contains the full reference to the object. Including all invisible panels required to build the page/object. But many of these intermediate layers (Panel 1/Panel 2/Panel 3/Panel 4 etc etc) you don't care about as you don't interact with them.
This is what the Alias map is used for. It should be a more concise and readable reference to a control. And give them sensible names.
EG.
Mapped name: Browser.Page.Frame.Panel.Panel.Panel.ButtonContainer.Panel.SaveButton
would probably have an Alias along the lines of:
Alias name: Browser.Page.ButtonContainer.SaveButton
(With names like that. If the save button mapped as "afxWNDsvBTNx53a", then change it's name to "SaveButton" as it's much easier to read!)
As other have said, your identification properties for object HAVE to be bulletproof and reliable. If they are not, you WILL have long term problems.
And again, as others have said, you can also use "helper" or "finder" functions instead of/as well as name maps.
Which is fine. But don't make them too broad. If you have a very busy website, with a lot of objects in the DOM, finding every single object needed during a run using "Browser.Page.<FIND OBJECT ROUTINE>" can come with a big performance hit. And if you run a test on a slower machine (say, using TestExecute on a lower power VM) the slower performance can cause problems with a test which works fine on a more powerful machine.
I use a mixture of maps and helper functions. Map the high level static stuff, dynamically find the low level, more changeable stuff. I also use generic control handlers to avoid writing application specific routines as much as possible. A control handling function is portable. An application handling function generally isn't.
Think of the information captured when you map objects as a baseline. You then need to make it reliable and readable!
thank you for your reply, I understand all your recommendations for the proper use of the test tool. As you mentioned, identification of the properties have to be bulletproof to avoid any mapping difficulties, I agree with you, but when I have object mapped that don’t carry no more properties to be defined as a single identification of the object or has no signification or also disabled, which solution will be possible on the choice of objects properties?
NB: according to lino tadro “ID” is not recommended for unique identifier of the Object to map, but Index it is.
Thank you for response
Hi,
I totally agree with you Colin_McRae when you say to use finders. In my opinion, mapping object on a web site is very bad as it is not permissive at all. In my case, i made my own finder using the testcomplete finder on a few properties : you can search for an ID, or an index, or a innerText... which can work if you have an object with no properties but text.
I think TestComplete should be improved, by implementing an internal pre-check prior to test running, in which it valides current name mapping and the use of these name mappings (aliases) in testscripts, to changes (especially on deleted objects)
See this feature request. (vote for it if you like the idea). Comments are also welcome.
Seems unlikely.
In order to pre-check/validate ALL objects required within a test, they would have to be present.
Which isn't going to happen ..... without running all the tests. Many object won't appear without pre-work (ie - making a bunch of selections or entering some data or whatever) so I don't know how TC would validate them without actually running test.
Having just read the feature request, I see staff have similar concerns as to how you would actually do it.
And I REALLY don't like the idea that it deletes things it can't find. I can see that causing more problems than it solves! Maybe flag them for deletion I suppose, but no way I'd want it just trashing stuff by itself.
Any time I get an updated version, I generally accept it will need a minimum of two runs. One to catch up with updates, changes and new functionality. And then one to run and store test results. Except that invariably turns into (a minimum of) three runs. Run to find the changes. Run to test the updates. Run to run the tests.
I've long since got past the point where I ever expect ANY automated test (well, anything even vaguely complex anyway) to be totally change-proof. It's simply not realistic. If a dev changes a table name in a DB, and you run queries/tests against that table, your test will HAVE to be updated somewhere. It's unavoidable.
For me, it's more about keeping updates as simple and easy manage as possible. Not trying to avoid them completely as you never will.
