From what I can tell, mapping all of the parent objects is only really neccessary in the Mapped Objects section and not so much in the alias section. Therefore, it would be nice if only the page objects and the objects interacted with were mapped in the alias section or some other means of keeping the objects in the alias section down to the bare essentials.
5 Comments
This is a manual process... I agree, it would be nice to have this automatically done, but the question is... how does TestComplete "know" which objects are the ones you want and which ones aren't? It's not always clear. For example, we have a web application where it may seem like certain panels are not necessary for the automation. However, we use them for referencing certain attributes and contents that, while not something a user would interact with, are needed in order to validate certain functionality. So, we include them in the Alias even though not strictle necessary.
I'll vote this one up, but I think it's going to be a bit tricky to "teach" TestComplete some algorithm to determine which objects to include in Aliases and which ones not to.What do you mean when you say, "referencing certain attributes and contents that, while not something a user would interact with, are needed in order to validate certain functionality”? Are you referring to using the “previousSiblingElement” sort of identification properties? Furthermore, regarding the validation of certain functionality, doesn’t the Mapped Objects area handle this sort of functionality? You seem to be eluding to alias functionality that I am not sure I am aware of. So I could just be confused.
So, let's say I have a button on a page. That button is what the user interacts with. When recording a test, that seems to be the only component that really needs to be mapped for that segment of the test. However, part of the test may actually be making sure that the container on the page (some DIV or other HTML component) that contains the button has a certain background color or alignment or something. So, it's not something that you "click" on as part of a test, but something that is observed. Most of the time, such container panels are things you wouldn't think of mapping in TestComplete. However, to interact with it in a test, you need to map it. It's not an easy algorithm to determine. So, to make TestComplete "smart" to exclude or include such panels is not necessarily an easy task.
So, for us, we map the WHOLE tree... and then, in the Aliases section, we highlight those things we don't need, right click, and select "Exclude" and the Alias is shortened to contain only those things we want while preserving the full mapping of the object.And just a note...as mentioned in one of your other requests, we don't use recording to record a full test. We manually construct our keyword tests, using recording only when necessary to "discover" certain workflows.
It's a mindset of viewing test automation less like just recording tests you're doing manually and more like software development, which is what test automation is. It's developing software to test other software. So, there is methodology and such that goes along with it. Think of the object identification/namemapping as the development of the UI of an application under test and the actual test "code" itself as the code behind the UI that performs the functions. Both take care, attention, and methodical practice to do well.Thank you for the information and all your help. I understand the importance of mapping the whole tree. This request would not undermine that, it would just cut down on the extent of the tree that is aliased.
If a middle man object, such as the panel that a button is in, is desired in the alias space, the user could simply drag the object down from the mapped objects list to include it in the alias space. I cannot see this being something that would be need too frequently. Whereas with the present set up, the extensive way TC populates the alias section results in a lot of cleaning post recording.
Although I know that recording cannot alone be leaned upon for test creation, I believe there are ways it could be more useful in this regard. It would be great if recording could be more reliably used to flesh out a name map and better establish foundational steps from which to build a test; it would be nice if it resulted in a foundation that did not need as much post clean up and polish.
