Test cases in a test set trigger multiple logins to VDI/VM

Background
Our robots run on VDI’s using App V packaging. The system (Windows 21H2) can take some time to log in the user and to initialize/customize the desktop enviornment for a user/ user group / robot.

In RPA automations, we handled this by using a start delay before every execution before the initialization stage in REFramework (not every transaction). This means that if we have 100 transactions, we only have to delay the robot until the applications are ready and loaded before handling the first transaction. This delay did not add too much to robot execution times, stability trumps over execution speed.

Issue with Test Cases
Now in Test Automation, this is becoming a challenge. For some reason each UiPath Test Case within a test set is run as a new automation. i.e. in a Test set A, with 4 test cases T1,T2,T3,T4 Each test case starts the UiPath executor and logs into the VDI, performs the test and logs out. In total there will be 4 login and logout actions.

In our case, this means that due to the delayed response of APP V, we have to use a delay in each test case to ensure that the Test Robot does not timeout while waiting for APP V to load the user interface.

Feature request
Could it be possible to run the test set (all four test cases) in one go? i.e. one login event, one executor running the 4 test cases and one logout event.

Our workaround with a delay for every test case will waste a lot of robot execution time. Would love to hear if such situations are considered.

Thank you for your efforts and consideration

1 Like

Hi Jeevith,

thx for the feedback. We understand the problem and have logged a feature request on our end.
Will keep you posted on the progress.

BR
Thomas

1 Like

Hello @ThomasStocker and @Gernot_Brandl,

We are currently working on a TA project where the above issue I described can decrease efficiency of our test cycle.

In this current scenario, we have a total of 331 test cases, each test case has to be run on 9 different instances and each of those test cases are data driven with a minimum of 7 variations.

(331 * 9 * 7) = 20853 Test case runs

Execution Time
Login using APP-V takes ~ 1,5 minute. Execution of test case takes ~ 1,5 minute and logout is instant - each test case execution will then take ~3 minutes

20853 * 3 = 62559 minutes

So in theory, UiPath will login to the machine 20853 times and due to the delay required by APPV there will be an idle time of (20853 * 1.5) 31279.5 minutes

If all test cases in a test set were to run without a forced logout i.e., if the UiPath Executor logged in once per test set, we at the minimum can save 31279.5 minutes! (assuming that we also have an uniform allocation of Test cases within a Test Set)


The USP of this project was that Automated Testing can improve test coverage and help test managers evaluate release candidates. The USP is hindered when a robot takes close to 44 days to run all test cases (using 1 testing robot) and ~10 days using all our testing licenses (4).

Our feature request in summary is to treat a Test Set as a single executor action and avoid logging off after execution of every test case in a test set.

Thank you for your efforts.

2 Likes

Hi jeevith,

fully understand the problem.
We are looking into it atm.
Will get back as soon as I have additional questions or suggestions.

@ThomasStocker can you make sure its something you can configure and isn’t enforced in a blanket way? As it can also be nice to have each test run as a separate job (causing the logout and login) as that means you can then spread the workload across multiple licences and machines, having the choice would be great.

Just wary of the change as often these things are done and the existing functionality gets removed in favour of the new way and we have to request it be returned.

Hi @ThomasStocker,

That sounds reassuring to us. Thank you.

I also agree with @Jon_Smith. This feature request ideally should not override the current behaviour but be added as new functionality.

For example, an additional switch / option while creating Test Sets either in Orchestrator or in Test Manager.