Forum Discussion
Thank You
There are so many screens in our application under test has controls with dynamic identification properties, more over there are multiple instances of same control will be present on same screen. Direct name mapping of each control is tedious here, instead name map one of the control from a group of similar controls and use the project level variables to identify varying properties to distinguish which GUI control to access by run time decision. Added more persistent variables to distinguish each control type and screen.
I am also adding new variable just by right clicking and picking the New Item menu. However I am loosing existing variables when I add new one.
(My project had 33 Project level temporary variables in use)
I would suggest there is a better way of handling the namemapping issues than creating a new persistent variable every time you need to add a varying property. Consider not having to map all your objects, for example. In our application under test, we have some tables that show up in our web application that are long, dynamic lists of data. From run to run, this list varies in length. So, mapping all the rows and columns in this table doesn't make sense. So, we use various "Find" functions to find what we want. FindChild, Find, NativeWebObject.Find, etc, all come into play. You can build a library of such functions to call within your tests that you can just pass in the parameters rather than having to put them in any set of variables.
There are other ways of dealing with dynamic properties... conditional namemapping is one, using wildcards is another. But honestly, if you're hitting 58+ variables just to handle your mapping, I'd really suggest going a different direction.
That said... there is no upper limit that I can find to adding variables to a project or project suite. So, why you're "losing" some is curious. There has to be something unique about how you're doing stuff. Keep in mind that the variables are stored in the PJS (for project suite) and MDS (for project) files. So, if you're adding variables and someone else is adding variables, and you check in changes to your source control, you could be accidentally over-writing changes that the other person made, resulting in variables "disappearing".
- Jeevan7 years agoNew Contributor
Thank you for suggestions, I would consider it for long run. We are also using Find functions to certain extend to identify controls, but realizing it is having very minimal scope in our automation. Should expand Find function approach as you said rather than persistent variables.
I was experiencing this variable removal strange behavior at my machine almost for a week. Somehow it got resolved just now , I am not sure what action got fixed the problem. Added few more variables to Temporary section and Saved all files, then deleted these temporary variables, Saved all files. Added a persistent variable on right clicking the last Empty Row in Persistent variable section and saved files. Variables were sorted in the order of Name column and I was right clicking in any row earlier to add new item. Once I picked the last row for right clicking, it started working; now I can able to add new variables from any row without loosing existing ones.
- Marsha_R7 years agoModerator
We have about 140 persistent variables and we've never had any trouble adding them. I agree with tristaanogre here. You shouldn't need them for name mapping at all, and you really don't want to start out one way and then have to change it later. Make the time now to do your name mapping the right way or you will likely regret down the road.
p.s. tristaanogre weren't you going to fix up that script extension from the contest that exported/imported persistent variables? Hint hint. :)
- dmiscannon7 years agoFrequent Contributor
Try this one. I made a few corrections to exclude the variable types that weren't supported by the script extension.
Related Content
- 14 years ago
- 10 years ago