Hello EveryOne, I need a better solution for the below problem. Can you pls help?
I need to login as a User A in the AUT
There is a login api limit which is restricted to 100 hits per hour. I have around 200 testcases where I login as User A and perform actions.
Because of the above limit, when I run all the 200 testcases at a time and if the limit is exhausted in between, the testcases later in the queue are failing
I was able to solve this by using Save Storage State keyword and re-using the same authenticated state file.
Now there is another limitation, the auth_token present inside the state file, will refresh after 15 mins. So before login as User A in each testcase, I’m checking if state file is older than 15 mins, if so then I’m logging in and creating the state file. is this the right way to do?
Grouping of testcases was not effective, since we need to do multiple login in same testcase, as User A, B, etc
some additional pointers
using pabot for parallel execution, hence using Run Keyword Once keyword to execute the Keyword “Login as User A”
What if some 5 testcases with same step, Login as User A checks for the age of the state file, and all those 5 testcase will login at the same time. So this is bigger problem I need a solution. I cannot use Run Keyword Once here because suite is running for more than an hour so the keyword has to run for multiple times when required
You have a great long laundry list of seemingly conflicting requirements, so lets break them down and deal with them one or 2 at a time:
We’ll start by trying to solve it without pabot and then add pabot later to speed things up
just to confirm it’s only login that’s limited to 100 hits per hour, if you could login once and run all 200 tests withing the time limit that would count as 1 hit on login?
Assuming yes:
You would solve this first part of the problem by having a Suite Startup perform the login then all test cases can run with the logged in user and then we have a Suite Teardown to logoff
Next we try to solve the auth_token being limited to 15 minutes
we update Suite Startup to be our own keyword that does the login not just a library keyword
in our login keyword we add a step that sets a suite variable for login time and we put in that variable the current time at login as seconds since epoch
next we create a keyword called something like check login
check login will get the current epoch time and compare it to the login time variable
current time - start time = time delta in sec
if time delta is greater than 13 minutes (well depends how long your individual test take to run I’m estimating 2 minutes per test here, adjust as you need)
call logout keyword
call login keyword again
Now all the tests can run with a single user as long as it takes to run them all with around 4-5 hits per hour to login
some tests need to run with UserA only, some with UserB only, and some with both
we can solve this problem with tags, tag the tests that need UserA with the tag RoleA, the ones that need UserB with RoleB, some test will have both tags and some will only have one or the other
Now in the *** variables *** section we define the username (and password) variables the login keyword uses
when we run robot we can use the --variable option to set the the username to use when we login (e.g. UserB)
we also use the --include to select the tests with the tag related to the use we set (e.g. RoleB)
now we can run 2 robots in parallel one to test all the test cases related to UserA and a second one to test all the test cases related to UserB, but to combine the results we need to use rebot after they both finished
Now we come to the pabot part, here it’s important to know if you just run pabot with no options how many processes would it run 4? 8? 16? this will depend on your machine, for the example below I’ll work as though it was 8, you can adjust my numbers as needed.
So the first important thing to know is if you can have UserA logged in twice concurrently or not.
I’m not so familiar with pabot, I got an example working with it as a demonstration but it’s not something I need, so hopefully someone else with more experience can jump in and guide better than me.
At a simple level if you can just log in multiple times with the same user, you can now take the 2 robots we ran in parallel above and run to pabot’s in parallel the same way:
on each pabot you would use --processes 4 to give you 8 total (you don’t want both pabot’s running 8 and overloading your machine)
8 robots x 5 max logins per hour is 40 logins per hour, so we are sill well under the 100
we still need to use rebot to combine the logs from both pabot’s at the end
Next steps
explore the --resourcefile option to pabot so you can have 1 pabot run with 8 processes and let pabot decide if the user is a RoleA or RoleB user (I don’t know how to get pabot to run test based on the tag received using the --resourcefile option, hopefully someone else can help with this?
explore whether the --argumentfile option is useful to you, I think this may be related to my question in the previous point?
if you can’t have UserA logged in twice concurrently (or UserB), this is where the RoleA and RoleB come in, you will need multiple UserA’s and UserB’s, e.g. (UserA1, UserA2, UserA3, UserA4, UserB1, etc), so when you setup your resource file you associate the users with their roles, and this is why we used RoleA and RoleB for the tags not UserA and UserB.
Don’t try to do the whole thing in one giant leap, take it step by step and implement one part at a time, what that part is working move to the next part, knowing you have a path to the end goal even if it’ll take you a few weeks/months to get there
Hopefully this is enough to get you going in the right direction,
