- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- The Diagnostic Tool
- Workflow Analyzer
- About Workflow Analyzer
- ST-NMG-001 - Variables Naming Convention
- ST-NMG-002 - Arguments Naming Convention
- ST-NMG-004 - Display Name Duplication
- ST-NMG-005 - Variable Overrides Variable
- ST-NMG-006 - Variable Overrides Argument
- ST-NMG-008 - Variable Length Exceeded
- ST-NMG-009 - Prefix Datatable Variables
- ST-NMG-011 - Prefix Datatable Arguments
- ST-NMG-012 - Argument Default Values
- ST-NMG-016 - Argument Length Exceeded
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-023 - Empty Workflow
- ST-DBP-024 - Persistence Activity Check
- ST-DBP-025 - Variables Serialization Prerequisite
- ST-DBP-026 - Delay Activity Usage
- ST-DBP-027 - Persistence Best Practice
- ST-DBP-028 - Arguments Serialization Prerequisite
- ST-USG-005 - Hardcoded Activity Arguments
- ST-USG-009 - Unused Variables
- ST-USG-010 - Unused Dependencies
- ST-USG-014 - Package Restrictions
- ST-USG-020 - Minimum Log Messages
- ST-USG-024 - Unused Saved for Later
- ST-USG-025 - Saved Value Misuse
- ST-USG-026 - Activity Restrictions
- ST-USG-027 - Required Packages
- ST-USG-028 - Restrict Invoke File Templates
- ST-USG-032 - Required Tags
- ST-USG-034 - Automation Hub URL
- Variables
- Arguments
- Imported Namespaces
- Recording
- UI Elements
- Control Flow
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Citrix Technologies Automation
- RDP Automation
- Salesforce Automation
- SAP Automation
- VMware Horizon Automation
- Logging
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Test Suite - Studio
- Extensions
- Troubleshooting
- About troubleshooting
- Microsoft App-V support and limitations
- Internet Explorer X64 troubleshooting
- Microsoft Office issues
- Identifying UI elements in PDF with Accessibility options
- Repairing Active Accessibility support
- Automating Applications Running Under a Different Windows User
- Validation of large Windows-legacy projects takes longer than expected
Test Cases
Application testing in Studio works in either VB or C#. You can create individual automation projects for scenarios such data verification or integration with your CI/CD pipeline. Design your workflow in Studio. You can perform automated application testing in VB or C#
- Perform application testing through test cases and data-driven test cases.
- Test automation projects can have multiple entry points if they contain several test cases with linear execution, as the activities are organized sequentially.
- Workflow execution is performed per test case unless other
XAML
files are invoked. - You can convert workflows to test cases, imports from other projects or create new ones.
You can create a test case by invoking a workflow from an existing project.
- Open your workflow in Studio.
-
In the Projects panel, right-click the workflow and choose Create Test Case.
-
(Optional) Select Mock workflow under test when you create your test case if you want to make a copy of your workflow where you can mock specific activities. If you have an existing mock file that you want to use, you can select it from the Mock dropdown. For more information, see Mock Testing.
- (Optional) Select a Template from the dropdown list if you have created one previously. For more information, see Test Case Templates.
- (Optional) Add the test case to an Execution Template. You need to have created an execution template first. For more information, see Create execution template.
- Click Next if you want to add test data.
-
Click Create to confirm changes.
A test caseXAML
file is created invoking the workflow with the following containers: Given, When, and Then. The file is invoked inside the Invoke Workflow File activity, part of the When container.
Arguments from the workflow are automatically imported. To view or add more arguments, click the Import Arguments button part of the Invoke Workflow File activity.
Both test cases and data-driven test cases are created as drafts by default. You need to set the test cases as publishable before publishing to Orchestrator. You can set individual or multiple test cases as publishable by right-clicking the workflows and then selecting Set as Publishable.
XAML
icon will turn blue as an indication that the test case is ready to be published and packaged in a NUPKG
file. To revert back to your workflow draft, right-click the workflow and select Ignore from Publishing.
You can publish the test cases to Orchestrator, to Robot defaults or a custom path. If you want to publish to Orchestrator, make sure your Robot or UiPath Assistant is connected to Orchestrator.
Publishing to Orchestrator is also required when you want to execute automated tests through Test Manager. Make sure to publish the package to the Orchestrator Tenant Process Feed, then link the test cases to Test Manager. Publishing the package in a different folder may result in execution errors.
To convert workflows into test cases right-click the workflow in the Project panel and select Convert to Test Case:
Result: The workflow becomes a Test Case, and is regenerated based on the BDD Test Case template.
XAML
files are added to your project as draft test cases.
Similarly to importing data collections into API Test Automation libraries, you can import such collections into your Application Testing processes using the New Service wizard.