I’m working on a UiPath test automation project where multiple test cases need to log in to the same application before executing their actual test steps.
Currently, I’m considering keeping the login flow as a reusable workflow and calling it from each test case.
What is the recommended approach in UiPath for this?
Should login be called inside every test case?
Should it be handled through Test Case setup/teardown?
Is it better to create one reusable login workflow and pass credentials through arguments?
How do you normally handle session reuse when multiple test cases are executed from Test Manager/Orchestrator?
What approach works best when tests need to run independently?
Would appreciate suggestions based on real project experience.
Yes, make login a separate reusable workflow, invoked from the Setup, with credentials passed via arguments (pull from Orchestrator Assets/Credential Assets, not hardcoded). This keeps login logic in one place, one change point if the app’s auth flow changes. Use reusable workflows for login and logout/cleanup when required.
Avoid relying on session reuse between test cases, especially when tests may run independently, in parallel, or on different machines. Each test should be self-contained and independently executable.
Also, make sure to create test cases for the reusable workflows (login and logout), because they might also fail in different environments.
Hi @Abhilash3 I would recommend keeping the login logic in a separate reusable workflow rather than duplicating the login steps inside every test case.
For example:
Login.xaml
Open/attach application
Enter username/password
Click Login
Validate successful login
Return login status if required
Then individual test cases can invoke this workflow before executing their actual validation.
However, I would still try to keep each test case independent. I wouldn’t rely heavily on one test case logging in and the next test case reusing the same session. That can create dependencies between tests — if the first test fails, subsequent tests may also fail, and parallel execution becomes difficult.
For a larger framework, another good option is to use an Execution Template and keep common initialization/login logic around the test case execution. This avoids adding the same setup activities manually to every test case.
Something like:
Execution Template
→ Initialize configuration/credentials
→ Open application
→ Login
→ Execute Test Case
→ Cleanup / Logout / Close application
Credentials should ideally come from a secure source such as Orchestrator assets rather than being hardcoded or directly maintained inside the workflow.
So my preference would be:
Reusable Login workflow + Execution Template + Independent Test Cases
I would reuse an existing authenticated session only where execution time is a major concern and the test scenarios are intentionally designed as an end-to-end flow. For normal regression tests, test independence is more important than saving a few login steps.
Hi @Abhilash3 ,
Create a reusable Login workflow and invoke it from your test cases or test setup.
Keep all login steps in a separate workflow (e.g., Login.xaml).
Pass credentials through In arguments or Orchestrator Assets.
For independent test cases, perform login within each test case (or Test Setup) so tests can run individually without depending on another test.
Use Test Case Setup/Teardown for common actions like login and logout to avoid duplicate code.
If tests run sequentially in the same session and application state is stable, you can reuse the session to reduce execution time. However, avoid making tests dependent on previous tests.
In real projects, the best practice is: Reusable Login workflow + Setup/Teardown + independent test cases for better maintenance, reliability, and scalability.
A good practice is to keep the login functionality in a separate reusable workflow and call it wherever required. This avoids duplicating the same login steps across multiple test cases.
For tests that need to run independently, I would recommend calling the login workflow from the Test Case Setup. This ensures that each test starts with a known and consistent application state.
A typical approach would be:
Create a reusable Login.xaml workflow.
Pass credentials securely using arguments or Orchestrator Assets.
Call the login workflow from Test Case Setup when each test requires a fresh session.
Use Teardown to log out or clean up the application state if required.
Avoid depending on a session created by a previous test case, especially when tests may run independently or in parallel.
If session reuse is needed for performance reasons, it should be carefully managed, but independent test cases are generally more reliable and easier to maintain.
I would create one reusable Login workflow and call it from each test case. Pass the credentials through arguments or use Orchestrator Assets/Credentials rather than hardcoding them.
For independent test cases, I prefer each test to log in and clean up its own session. That way, tests don’t depend on the execution order or another test’s session.
You can keep the common login in a reusable workflow, and call it from the Test Case setup if that fits your project structure. Test Manager is then used to group and execute the test cases through test sets.
As per my experience, you can follow this approach:
Create an Object Repository for each application you use in your Test Automation Project.
Create reusable workflows using the captured elements and publish them as a Library.
Install the published package as a dependency in your Test Automation project.
Keep the login module within the individual test case rather than placing it in the Execution Template. This ensures that each test case can run independently. And Retry mechnism can be implemented on test case level intead of some part of it.
Pass credentials through arguments/configuration.
With this approach, each test case manages its own login/session and can be executed independently.
