aims's avatar
aims
Occasional Contributor
6 years ago
Status:
New Idea

Name Mapping Improvement

Dear All,

Currently, Name mapping behaves/works as a reference especially when testing web pages or .net programs. When a script is recorded and i am referring to script and not to Keyword test the objects are placed in Name Mapping. On the next step, that a user wants to record a new procedure or wants to add on an existing one TC makes a new reference to already existing object in name mapping.

My suggestion is to pre-load / have the objects saved or stored in the name mapping so that during the recording if an object already exists TC will use it as is instead of making new reference refraining from piling up with the same object. This will make life a lot easier as it creates grounds for multiple recording Techniques. For example a tester can use TC to learn the objects once using the Object Spy and then use them during the creation of the script. A more advance scenario will be to use the object spy on the highest level of objects and the spy to detect all the child objects from the screen and then to place them in Name Mapping with one go. I have seen that in other testing product and provides a great flexibility to the test developer. This will require though to change the Name Mapping approach from reference to storage.

Dear community members, If you wish for me to further expedite on this i will be more than happy to participate or if you should require further information please do not hesitate to contact me.

Best Regards,
Minas Vlachos.

4 Comments

  • tristaanogre's avatar
    tristaanogre
    Esteemed Contributor

    If you're having as situation where an object is mapped... and then when you record a test it creates another mapping for the same object... that's a problem with your mapping criteria.  What you have used as properties to define the object identification are insuffient to uniquely identify it and so each time you reference it, a new object mapping is created.

     

    In truth, NameMapping is more than just a reference... it is a storage.  It is the storage of the object identification criteria to be used by the internal object recognition engine so that, when you want to reference an onscreen component, TestComplete can find it.  If your NameMapping mapping criteria and structure are sufficiently robust and properly maintained, you will not have those problems that you have described.

     

    And both techniques you described are available.  You can map everything ahead of time and have them used in your tests as you create them... or you can map only those items you need at the time.


    So... what it sounds like is that, rather than needing a development change to NameMapping, you need to examine how you've mapped your components to make them better at object identification.

  • cunderw's avatar
    cunderw
    Community Hero

    Agreed with what tristaanogre said. This is definitely more of an issue with how you have your mapping setup. Auto-mapping from recording is a great first step, but will never be your final effort for mapping objects. You HAVE to go in and manually adjust your ID properties and values, extended find, etc... Test complate mapped the object again because there is a dynamic property in the object or it's parents that is changing. So as far as test complete know it IS a new object.

     

    I see this a lot with people newer to test complete. I highly suggest spending time reading through everything in the documentation about object identification:

     

    https://support.smartbear.com/testcomplete/docs/testing-with/object-identification/index.html

     

    If you want a simple app to test approaches with, http://www.uitestingplayground.com/ is very valuable. 

  • aims's avatar
    aims
    Occasional Contributor

    Dear tristaanogre ,

     

    Thank you very much for your input. There is no problem with the recording as if you extend the name mapping criteria the objects are recognised and referenced as expected in name mapping as you indicated. I came across to a situation like that in the past when i was trying out alternatives to what I am using as a name mapping technique, which is to use the object spy to learn the objects and then i use my own meaningfull variables to right my scripts. I don t use Keyword testing, nor record and play due to the complexity of the application under test. 

     

    Having to perform this tasks it came as a thought how much easier would have been if Test Complete had the ability to learn all the objects on the screen or even better if you spy on a high level object whether is a form or a panel  and TC had the ability to learn all of the child objects under the high level one. This is a feature i ve used back in the days were i used WinRunner by Mercury. As "traveled back i time" i recalled that besides the aformentioned functionality this tool stored the objects which then they were pre loaded each time the test was accessed either to be ran or to be modified.

     

    From my perspective objects in TC are referenced and not stored . This was also the comment made from a TC engineer during a conferece call. From your point of view yes it is stored. No debate about it. I clearly see your approach.

     

    Anyhow this was ust a suggestion which i think that will help alot of testers who deal with complex applications especially during the creation of the test script.

     

    Once again i would like to thank you for your comments / input. 

     

     

  • aims's avatar
    aims
    Occasional Contributor

    Dear cunderw 

     

    Thank you for taking the time to put your comments into this suggestion.

     

    Obviously I am not referring to new people on test complete. The idea was to make life a bit easier to users who deal with complex applications and large development teams to reduce the overhead of test creation. From my point of view objects are referenced in the name mapping. Dynamic properties are dealt differently as I use regular expression or wild chars and they function as expected.

    The approach we use and works fine for us is to use the object spy to learn the object and assign it to a meaningful variable which is straight forward to maintain. This is working for us due to the complexity of our application.