Forum Discussion
Can I ask why you don't want to just define the local variables in the keyword test itself?
I've considered using a Code Snippet to add a variable dynamically within a keyword test. Like Project variables and ProjectSuite variables, using code, you can add and/or delete variables on the fly (KeywordTests.MyKWT.Variables.AddVariable is a viable function). However, building a keyword test around it will be difficult because, until the variable is added, you can't utilize it in any keyword test operations. You would have to resort to Code Expressions anytime you want to use the dynamically declared variable using KeywordTests.MyKWT.Variables.VariableByName(). Also, note that the variable would persist at the end of the keyword test meaning you would have to make sure you dispose of it after you're finished with it or add logic to detect whether or not it exists before you add it. It just seems that this over-complicates things that can be achieved simply by declaring the variables at design time of the KWT.
The way I think of Keyword tests is that each one is a function declaration, much like declaring a function in JavaScript:
function Test() { var myVar; myVar = 'My Test'; Log.Message(myVar); }
Variables within functions are declared when the function is declared. Even in JavaScript, while a variable declaration can happen any time within the code, they are "hoisted" to the top and effectively declared up front (unless you're running in strict mode but I digress). Anything added dynamically are properties added to objects, elements added to arrays, rows added to tables, etc.
As Marsha_R mentioned, it would be interesting to know why you want to do things this way. What problem are you attempting to solve or what effect are you attempting to achieve? We might be able to find an alternative. For that matter, if it's a matter of having common global variables to be used across all your keyword tests, it might just be best to declare them as Project or ProjectSuite variables up front or build them into read/write properties in script extension runtime objects.
- RajeshVV7 years agoContributor
Let me give an example.
TestCase1 - Validate the values from a form with Fields - Field1 set to "a", Field2 set to "b"
TestCase2 - Validate the values from a form with Fields - Field1 set to "c", Field2 set to "d"
Here we have the same validations, but the "Field1" has been changed to "NewField1"
TestCase3 - Validate the values from a form with Fields - NewField1 set to "e", NewField2 set to "f"
in this case we need to rename the variable and also the values assigned to them.
Hence, the instructions to set the field name and field value should be dynamic which stalls me at the point to declare/create and set values to the variables dynamically.
- tristaanogre7 years agoEsteemed Contributor
I'm not sure why the variable name needs to change. All you are doing is validating the contents of two fields in your application under test. The names of those fields in the AUT are not directly related to the variable names in your test code.
What I would do is write your validation to take as string pairs the name and value, something like "Field1|e". That would then be passed as a parameter to a code routine which would take the first string as the field name and the second string as the field content (use aqString.GetListItem to get the individual pieces). Then execute your validation code using a "Find" function to find the field and validate it's contents based upon the passed in strings.
This routine could then be repeated for an field/value pair. If I was doing this ALL in script code, I would even make it an object like {Field1: e, Field2: c} and parse it out that way but I've had difficulty sending objects like that from Keyword Tests to script code so the string pair works best.
This way, you don't have to worry about dynamically changing variable names but simply use a single parameter on a libraried code function to do the validation.
There are probably a number of variations of doing this kind of thing but, generally, what you are looking to do doesn't require dynamically changing variables but a validation function that receives the field name and value as parameters and does the validation that way. No need to create/rename a variable every time you do your validation.
- Marsha_R7 years agoChampion Level 3
Yes, what tristaanogre said! I can understand not wanting a million variables to be declared, but you really can just use the same ones over. If combining everything into one pair is too confusing, then just have a few pairs, one for each different type, but making them permanent variables will take one complication out of your testing.
Related Content
Recent Discussions
- 2 days agovladd1