I need to click on element based on what value it contains..but I want to set this value in test run or keyword definition (best option is in the test I guess) How should I do it?
the variable containing xpath should look like that:
${DROPDOWN ITEMS} xpath=//*[contains(@class,'listitem-element')]/span[contains(text(),'${second_number}')]
This locator works when I replace the variable with actual number like '002', but I want to have it more general..
In keyword definition I use it like:
Choose Value From Dropdown
focus ${DROPDOWN ITEMS}
click element ${DROPDOWN ITEMS}
and in test I just call the keyword
my question is where and how to set the variable value of ${second_number} variable used in xpath? PS:the xpath definition, keyword and test are each in separate files thank you!
You can define variables when you fire off your test suite by using arguments. Here is the documentation for it
Right now, you would leave your xpath as it is. Keeping the ${second_number} inside. Now you can either define it within the argument or within the argument file. They do the exact same thing, but one is neater. Just to get it working I would just worry about putting it directly in the console.
This will tell pybot to create a variable called ${second_number} with the value of 002. It does not save this inside the test, so after the test is completed, it will forget the variable.
Once this works, you can then move this into a Argument file Or if you want you can even define it inside a Variable file where you can store all of your variables and then call them within the argument file / within the console.
Any questions do ask and ill try to help out
how about using the
set suite variable
keyword?I use similar approach in my SUT, as it works with fairly complex objects, both precreated and dynamically generated during the tests executions - and their main user-identifiable attribute is the displayed name. Here's simplified version of my flow, and it's based around string substitution.
Starting off from the variables file - a simple collection of selenium locators, the value of the locator has a "special" string, which will later be substituted:
Then, in the keyword files there are private keywords for returning the proper locators, for example for this one:
Why the visibility check? Simple - to fail as early as possible if there's no such object currently in the SUT, and to have uniform error message, independent of how is the element further used (clicked on, checked for presence, attribute retrieval, etc.)
Then, a follow up user keyword for performing actions on the element uses the previous one:
Finally, the test cases use the keyword to work with any data you deem neaded:
This approach applies fairly well for negative tests also - for example, to check a value is not present, a test case would contain:
Thus we're both using selenium checks for the absence of the element, and keeping the test case close to real-life expression - a description of what should happen, with no special syntax and SE keywords.
please excuse any typos and minor syntax omissions - it's not easy to type on a mobile that much, next time I'd think twice before taking it on :D