UI (browser) testing via Gitlab runner

[rstelly]

I am able to run UI tests from a Gitlab runner, but it disconnects from the remote desktop - which is expected (https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/keeping-computer-unlock...) I am wondering if there is anyway to re-target that session that was created and continue to run tests from that session.

[AlexKaras]

Hi,

Not sure what do you mean as "re-target that session", but check if Session Creator is something that you are looking for: https://support.smartbear.com/testcomplete/docs/working-with/automating/session-creator/index.html

[rstelly]

I am running the test using Sessioncreator.  I want to know if there is a way to run tests using the session that was created in a previous test execution.

[AlexKaras]

Hi,

If the session remains active and not locked (as it is, for example, in Azure when Azure client is set up to execute not as a service but as an application), then the session will be reused.

If the session gets to be locked, then it must be unlocked. This can be done with either Session Creator or some third-party utility.

[rstelly]

Ok, that makes sense.  Will that ruin the ability to access the UI and if it does how can I prevent this?

[AlexKaras]

Active not locked user session is required for UI tests.

This is not TestComplete's requirement, but essential behavior of the Windows OS. If the user session is absent or is locked, then Windows just does not render UI and thus TestComplete cannot access and interact with it.

If your test does not depend on UI (for example, if test code just makes COM calls or some other actions that do not require UI), than such test can be executed on the locked machine.

[rstelly]

So is there a workaround?  Having to start a new remote desktop session everytime I want to run a gitlab pipeline is not a viable solution.

[AlexKaras]

Hi,

You may disconnect RDP session at test end via batch file like this: https://support.smartbear.com/testcomplete/docs/testing-with/running/via-rdp/keeping-computer-unlock.... Note that this batch file must be executed with elevated privileges (i.e. Run As Administrator).

[rstelly · Accepted solution]

Thank you.  It seems that the potential solution is that my session creator command was using the /UseActiveSession flag.  I think if I get rid of it, my problem should be solved