Suites interfere with each other while parallel execution using Pabot

Extensions
1

Hi,
I’m facing interference of tests while doing parallel execution of below suites using Pabot. Same variable ${record_to_select} needs to be set everytime ‘Create’ keyword is called and is passed as argument to other keywords within the same test test1 of each suite. But ${record_to_select} value should be specific to each suite and should not be shared by other suite tests. I would appreciate if someone helps me in resolving the issue with a solution.

suite 1
*** Test Cases ***
Test 1
Create record
Approve record
Amend record

suite 2
*** Test Cases ***
Test 1
Create record
Decline record
Amend record

suite 3
*** Test Cases ***
Test 1
Create record
Close record
Reopen record

*** Keywords ***
Create record
${New_Created_Record} Get Text css:.classname
Set Suite Variable ${record_to_select} ${New_Created_Record}

Approve record
Select item ${record_to_select}
Approve Item ${record_to_select}

Amend record
Select item ${record_to_select}
Amend Item ${record_to_select}

Decline record
Select item ${record_to_select}
Decline Item ${record_to_select}

2

Am i missing something or why not create record_to_select in suite setup ?

3

Hi,

I would say that expected behavior is that suite1 has ${record_to_select}=R1
Then suite2 has ${record_to_select}=R2.
But @Yuga_rfa is experiencing value R2 to be used in suite1/test1.

As it seems these are different robot suite file, I would also expect the variable to “stay” in suite1 scope.
Have you tried to define variable as a Test variable in the kwd (but your test have same name so I’m not sure it will work) ?
Tbh I use sometimes suite variables as you show, but I would rather pass it as argument and use RETURN if needed.
This should help with issue, and ease understanding of your code later, when you won’t remember from where this damn variables pops up :slightly_smiling_face:

Regards
Charlie

4

Hi @CharlieScene ,

Thanks a lot for your reply.
Given Suite and test names in above comment are just for understanding the problem.

But in real time, I have implemented different names for Tests within each suite.
As suggested by you, I’ve tried making it as Test variable in the kwd, but still no luck.

I didn’t get the other solution you are suggesting by defining it as suite variable and using ‘RETURN’. Can you please add a sample piece of code for better understanding.

Regards
Yuga

5

Hi

I was mentioning the fact that your variable is passed as an argument and obtained from the first Create keyword. In this case there is no SUITE shared variables all over the tests.

Suite1
*** Test Cases ***
Test 1
    ${record}    Create record
    Approve record    ${record} 
    Amend record      ${record} 

Suite 2
*** Test Cases ***
Test 1
    ${record}    Create record
    Approve record    ${record} 
    Amend record      ${record}

Then keywords this way:

*** Keywords ***
Create record
    ${New_Record}    Get Text css:.classname
    RETURN    ${New_Record}

Approve record
[Arguments]    ${record}
    Select item     ${record}
    Approve Item    ${record}

Amend record
[Arguments]    ${record}
    Select item    ${record}
    Amend Item     ${record}

Decline record
[Arguments]    ${record}
    Select item     ${record}
    Decline Item    ${record}

Regards
Charlie

2 Likes
6

Hi Yuga,

when running tests in parallel, you need to be extra careful the tests do not select the same record as another test in a parallel process out you will get this type of interference.

@CharlieScene suggestion is a great example of how to do this.

You also need to ensure that the Create record keyword is getting the record id from the creation process and not from a subsequent search result, relying on taking the first result from a search result set is a sure way to get collisions when executing tests in parallel. when using parallel execution the only safe way to use search results is when you search for the record number and get exactly 1 result.

Hope this helps,

Dave.

7

Another way to simplify your tests/keyword and avoid similar would be to pass the action on the record as an argument too:

Suite1
*** Test Cases ***
Test 1
    ${record}    Create record
    Modify Record     Approve    ${record} 
    Modify Record     Amend      ${record} 
    Modify Record     Decline      ${record} 

*** Keywords ***
Create Record
    ${New_Record}    Get Text css:.classname
    RETURN    ${New_Record}

Modify Record
[Arguments]    ${action}     ${record}
    Select item     ${record}
    ${action} Item    ${record}
1 Like