How to use variable, which value should be set in keyword or test, in XPATH?

Question

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!

Answer 1

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:

*** VARIABLES ***
    ${DROPDOWN ITEMS}    xpath=//*[contains(@class,'listitem-element')]/span[contains(text(),'SELENIUM_PLACEHOLDER_CHANGE_ME')]

Then, in the keyword files there are private keywords for returning the proper locators, for example for this one:

*** KEYWORDS ***
    _Return Selenium Locator For The Dropdown Item Named
        [Documentation]    Verifies the desired dropdown item is valid, ando returns its locator (not Webelements!!)
        [Arguments]    ${name}

        # change the placeholder with the actual UI name
        ${loc}=    Replace String  ${DROPDOWN ITEMS}    SELENIUM_PLACEHOLDER_CHANGE_ME    ${name}

        # why? Rationale explained below
        Element Should Be Visible    ${loc}    message=The dropdown does not have an item called ${name}

        [Return]    ${loc}

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:

    # the user keywords
    Choose Value From Dropdown
        [Documentation]    It does what it does :)
        [Arguments]    ${the value}

        ${loc}=    _Return Selenium Locator For The Dropdown Item Named    ${the value}

        # as you can see, no checks is the element real - that'she offloaded to the helper keyword ^
        Focus Element    ${loc}
        Click Element    ${loc}

Finally, the test cases use the keyword to work with any data you deem neaded:

*** TESTCASE ***
The dropdown should do X
    [Documentation]    Steps: 1, 2, 3, etc

    # do the normal steps you'do do
    Choose Value From Dropdown    my current value

This approach applies fairly well for negative tests also - for example, to check a value is not present, a test case would contain:

    Run Keyword And Expect Error    The dropdown does not have an item called no_such_element    Choose Value From Dropdown    no_such_element

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

Answer 2

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.

pybot -v second_number:002 nameOfTestFile.robot

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

Answer 3

how about using the set suite variable keyword?