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.
Colin_McCrae It doesn't have to be ALL objects, it could be screenbased. Or on a start/stop base. (Tester presses starts to start the examination, and stops it, and after that TC does the compare.
See the comments on the mentioned feature request.
TC could make a match (screenbased) on the previously mapped objects/testscripts, and the current screen. This is very useful in Agile environments, in which the application changes every day, and the tester doesn't know where/what has changed.
Of course it's not up to me HOW to do it. (I'm not a programmer), it's just that with this feature request TC could increase market value for Agile / Devops environments significantly). In such environments there is no time for scripting/testscript mainentance: the intelligence should be built in the tool (TestComplete in this case) itself. It could be done because similar logic is already built into TC already, however it should be extended to the testrun phase. It's important for a testtool to have good bindings to the AUT. Like said in Agile the AUT changes frequently and TC should be changed to make it easier to work with UI changes in the AUT.
For me deletion is preffered: I like to have as much clean namemapping model as possible. Things which are not used please delete them. Could be different in different environments therefore this behaviour should be configurable (deletion/marked for deletion/disabled, whatever) in main configuration.
Changes are not all alike. UI changes can more easily be tackled by the tool (see feature request) then validation on DB values in the testscriptlogic itself. Thats where the scripter of the future will become more focused on. Detection of UI-Changes and handling them, need to be done by the intelligence of the tool.
