Hello
I was attempting to streamline a variety of my automation scripts in KAR by storing selectors I kept re-using in a script within a Global Variable, and was then creating routines directly within the scripts themselves, using while loops. The routines were kept relevant to the current DOM element by passing through a specific value, using a pre-defined variable.
e.g. Within the script…
store | SomeAreaName | CurrentArea
while | X<Y
click | ${GlobalVariable.DoAllTheStepsToTheArea}
storeEval | X+1 | Y
endWhile
Within Profiles…
DoAllTheStepsToTheArea | //div[@data-testid=‘${CurrentArea}’]/button
When the script executes, it correctly fetches the Global Variable, but the ‘CurrentArea’ variable is never then expanded, so the pre-defined variable (which is present in KAR’s Variables tab at the time) isn’t populated within the command.
Instead, it just leaves the variable name in, thus it literally tries to execute the following, and fails:
//div[@data-testid=‘${CurrentArea}’]/button
What I was expecting it to do in the example above would be to generate the following:
//div[@data-testid=‘SomeAreaName’]/button
Please help!
PS. If I was desperate, I could probably work around this, and maintain the full XPath (without the dynamic variable’s contents) across two GlobalVariables, but that feels messy. e.g.
In Profiles create…
DoAllTheStepsToTheAreaPt1 | //div[@data-testid=’
DoAllTheStepsToTheAreaPt2 | ']/button
Which would then be called as ${GlobalVariable.DoAllTheStepsToTheAreaPt1}${CurrentArea}${GlobalVariable.DoAllTheStepsToTheAreaPt2}
Or alternatively, abandon my use of GlobalVariables for any selectors, where it needs to dynamically populate values. Neither option is desirable.
Change the single quotes on the above to double quotes and see if that does anything.
Pretty sure I already tried that, also made an attempt at adding an esc. char. before either the ${ or the ’ (can’t remember which now).
There may be some workaround to this that remains ‘neat’, but short of building a new variable that constructs the full XPath on the fly, and then using that (instead of doing it directly within the command i’m executing, but you’d have to ‘rebuild’ this every time you call it, otherwise it would store the value in memory when initially declared only), but this doesn’t have massive benefits (e.g. it then means making the scripts longer again, partially defeating the point of using global variables in the first place).
Beyond this though, i’m not sure of other ways around it (other than just including all of the variables directly within the script, and not using Global Variables for it at all).
Have continued to explore this issue. Can verify that the issue isn’t isolated to Global Variables, but the general use of a variable within another variable.
It will only ever resolve one layer deep, so may expand VarX from testing.${VarX} into ‘testing.somecode.${VarY}.something’, but it never then tries to parse the value for VarY, it merely treats it like a text string.
Similarly, there appears no way to keep ${VarY} as a dynamic variable either, so when you ‘declare’ it initially, it statically creates it based on what VarY equals at that point in time, as apposed to checking for the current contents of this variable at the point you subsequentally call it.
I’ve currently resorted to constructing my ‘dynamic’ variables using the following syntax: ${GlobalVariable.X1}${DynamicVariable}${GlobalVariable.X2} each point prior to executing the related command, but this means i’m still ending up with more bloated ‘code’ than i’d otherwise have had, requriing more maintenance.
The only ‘advantage’ is that if any maintenance required can be done within the values stored within the Global Variables, at least i’ll then only be altering that, as apposed to every instance of it.