Anyone who has done dynamic identification may find this option useful, but there are pros and cons to doing this.
Building a dynamic identification string, especially when you have more than 2 anchors, can sometimes be difficult to do without making a typo, or coming back to an action line with a large dynamic identification can be hard to read or understand. We created a c# scripted action that allows you to create dynamically identified controls that are identical to the way you would create them in an interface entity. The benefits are it's less likely you'll make a typo or forget an end bracket or double parenthesis somewhere and it's much easier to read and interpret after not looking at a test module for weeks or months. The downside is it does take up more lines in the test module. Below you can see an example of identifying a link anchored within a div that is anchored within another div.
The 'dynamic element' action has two defined arguments, ta name and ta class which you use the same as you would if you were defining a control in an interface entity, the other arguments you fill in yourself just as you would in an interface entity. This allows you to define any attribute and value pairing. You can also use regular expressions on the values just like you would in an interface entity.
Below is the result of running this short script, and you can see it created three variables - top div, div, and open link. Each of those variables contains the dynamic identification definition for finding that control.
This is the definition of the action from within Test Architect
Attached is the method to be added to the c# harness for the action, as well as shown below:
private void BuildDynamicDefinition()
{
string def = "[";
int argCount = Interpreter.AbtLibrary.GetArgumentCount();
Our engineers prefer to use this action over building the dynamic identification strings manually and feel it makes reading test modules and actions they are unfamiliar with or haven't looked at in some time much easier than trying to decipher a long dynamic identification string. Maybe others will find the same.
Thanks!
Hien Nguyen
said
over 7 years ago
Very nice job. Thank you very much Danny for sharing.
Danny Oslin
Anyone who has done dynamic identification may find this option useful, but there are pros and cons to doing this.
Building a dynamic identification string, especially when you have more than 2 anchors, can sometimes be difficult to do without making a typo, or coming back to an action line with a large dynamic identification can be hard to read or understand. We created a c# scripted action that allows you to create dynamically identified controls that are identical to the way you would create them in an interface entity. The benefits are it's less likely you'll make a typo or forget an end bracket or double parenthesis somewhere and it's much easier to read and interpret after not looking at a test module for weeks or months. The downside is it does take up more lines in the test module. Below you can see an example of identifying a link anchored within a div that is anchored within another div.
The 'dynamic element' action has two defined arguments, ta name and ta class which you use the same as you would if you were defining a control in an interface entity, the other arguments you fill in yourself just as you would in an interface entity. This allows you to define any attribute and value pairing. You can also use regular expressions on the values just like you would in an interface entity.
Below is the result of running this short script, and you can see it created three variables - top div, div, and open link. Each of those variables contains the dynamic identification definition for finding that control.
This is the definition of the action from within Test Architect
Attached is the method to be added to the c# harness for the action, as well as shown below:
private void BuildDynamicDefinition()
{
string def = "[";
int argCount = Interpreter.AbtLibrary.GetArgumentCount();
for (var x = 2; x < argCount; x++)
{
string prop = Interpreter.AbtLibrary.GetArgumentName(x);
string value = Interpreter.AbtLibrary.GetArgByIndex(x);
while (value.Contains(".*.*"))
{
value = value.Replace(".*.*", ".*");
}
def += String.Format("{0}={1},", prop, value);
}
def = def.Substring(0, def.Length - 1) + "]";
Interpreter.AbtLibrary.Assign(Interpreter.AbtLibrary.NamedArgument("ta name"), def);
}
Our engineers prefer to use this action over building the dynamic identification strings manually and feel it makes reading test modules and actions they are unfamiliar with or haven't looked at in some time much easier than trying to decipher a long dynamic identification string. Maybe others will find the same.
Thanks!