- Release Notes
- Getting Started
- Setup and Configuration
- Automation Projects
- Dependencies
- Types of Workflows
- Control Flow
- File Comparison
- Automation Best Practices
- Source Control Integration
- Debugging
- Logging
- 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-NMG-017 - Class name matches default namespace
- ST-DBP-002 - High Arguments Count
- ST-DBP-003 - Empty Catch Block
- ST-DBP-007 - Multiple Flowchart Layers
- ST-DPB-010 - Multiple instances of [Workflow] or [Test Case]
- ST-DBP-020 - Undefined Output Properties
- ST-DBP-021 - Hardcoded Timeout
- 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-017 - Invalid parameter modifier
- 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
- Coded automations
- Introduction
- Registering custom services
- Before and After contexts
- Generating code
- Generating coded test case from manual test cases
- Trigger-based Attended Automation
- Recording
- UI Elements
- Selectors
- Object Repository
- Data Scraping
- Image and Text Automation
- Citrix Technologies Automation
- RDP Automation
- VMware Horizon Automation
- Salesforce Automation
- SAP Automation
- macOS UI Automation
- The ScreenScrapeJavaSupport Tool
- The WebDriver Protocol
- Extensions
- About extensions
- SetupExtensions tool
- UiPathRemoteRuntime.exe is not running in the remote session
- UiPath Remote Runtime blocks Citrix session from being closed
- UiPath Remote Runtime causes memory leak
- UiPath.UIAutomation.Activities package and UiPath Remote Runtime versions mismatch
- The required UiPath extension is not installed on the remote machine
- Screen resolution settings
- Group Policies
- Cannot communicate with the browser
- Chrome extension is removed automatically
- The extension may have been corrupted
- Check if the extension for Chrome is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and Incognito mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Chrome
- Chrome Extension on Mac
- Group Policies
- Cannot communicate with the browser
- Edge extension is removed automatically
- The extension may have been corrupted
- Check if the Extension for Microsoft Edge is installed and enabled
- Check if ChromeNativeMessaging.exe is running
- Check if ComSpec variable is defined correctly
- Enable access to file URLs and InPrivate mode
- Multiple browser profiles
- Group Policy conflict
- Known issues specific to MV3 extensions
- List of extensions for Edge
- Extension for Safari
- Extension for VMware Horizon
- Extension for Amazon WorkSpaces
- SAP Solution Manager plugin
- Excel Add-in
- Test Suite - Studio
- Troubleshooting
- About troubleshooting
- Assembly compilation errors
- 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
- Validation of large Windows-legacy projects takes longer than expected
Studio User Guide
Before and After contexts
BeforeRunContext
(Setup): The Before execution is used to perform actions before the main execution of the test case. It is often used for setting up the initial state of the test environment and preparing resources. Some common use cases for the Before context include:- Initializing variables or data required for the test.
- Setting up connections to external systems or databases.
- Logging the start of the test execution.
- Opening applications or web pages that the test interacts with.
- Setup exceptions specific before running the test case.
AfterRunContext
(Teardown): The After execution is used to perform actions after the main execution of the test case is complete. It is typically used for cleaning up resources, finalizing operations, and recording the results of the test. Common use cases for the After context include:- Closing applications or web pages used during the test.
- Releasing resources, such as database connections or network resources.
- Catch and print out exceptions recorded in the Before context and main execution.
IBeforeAfterRun
interface adjacent to the main class, and then
implementing your own custom logic for these actions.
BeforeRunContext
, you can find
the following code
snippet:// Context of the run before the execution.
public class BeforeRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
}
// Context of the run before the execution.
public class BeforeRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
}
This context represents the state before the execution of the automation. It contains information about the relative path of the workflow being executed. You can set up exceptions here, according to your use case.
AfterRunContext
, you can find
the following code
snippet:// Context of the run after the execution.
public class AfterRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
// The exception caught in execution if any.
public Exception Exception { get; set; }
}
// Context of the run after the execution.
public class AfterRunContext
{
// The relative path of the workflow.
public string RelativeFilePath { get; set; }
// The exception caught in execution if any.
public Exception Exception { get; set; }
}
This context represents the state after the execution of the automation. It includes details about the relative path of the executed workflow and any exception caught before and during the execution.
Before
and main executions operate concurrently, capturing
exceptions that surface during execution. Any exceptions thrown during these phases
are captured and stored in the AfterRunContext
, leaving it as null
if no exceptions occur.
Before
and main executions run, the After
method is executed. If an exception is thrown during the After
run,
then the execution ends, and the corresponding exception is thrown.
Before
and After
runs, they are bundled into an AggregateException
.
You can implement the Before and After executions interface directly within your coded test case.
- Inside the public class where
your coded test case resides, add the
IBeforeAfterRun
interface. This will be highlighted in red, indicating potential fixes.public class MyTest : CodedWorkflow, IBeforeAfterRun
public class MyTest : CodedWorkflow, IBeforeAfterRun - Choose Show potential
fixes or press
Ctrl + .
and select Implement interface.This will generate a default interface as follows:public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }
public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Modify the implementation
according to your needs.
In the provided code example, the context logs a message before execution and checks for exceptions afterward.
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }
.cs
files within your project, using a custom partial
class.
- Create a Code source file. This
is where you implement the Before and After executions interface. For this
example, name the file
TestCaseBase
.- Add the
IBeforeAfterRun
interface next to the public class. This will be highlighted in red, indicating potential fixes.Note: The custom partial class (TestCaseBase
in this example) must inherit theCodedWorkflow
class. This allows othercs
files, that inherit the custom partial class, to run as expected.public class TestCaseBase : CodedWorkflow, IBeforeAfterRun
public class TestCaseBase : CodedWorkflow, IBeforeAfterRun - Choose Show potential
fixes or press
Ctrl + .
and select Impelment interface.This will generate a default interface as follows:public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }
public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Modify the implementation
according to your needs.
In the provided example, the context logs a message before the execution and checks for exceptions afterwards.
public void After(AfterRunContext context) { if (context.Exception != null) { throw context.Exception; } else { Log("Test " + context.RelativeFilePath + " finished with no exception."); } } public void Before(BeforeRunContext context) { Log("Execution started for " + context.RelativeFilePath); }
public void After(AfterRunContext context) { if (context.Exception != null) { throw context.Exception; } else { Log("Test " + context.RelativeFilePath + " finished with no exception."); } } public void Before(BeforeRunContext context) { Log("Execution started for " + context.RelativeFilePath); }
You can now use this custom partial class to use the same Before and After executions interface only for the.cs
files which inherit it. - Add the
- Create a coded automation. For
this example, create a coded test case named
TestCase
. To use the same Before and After executions interface from the custom partial class, ensure that the coded test case inherits from this partial class.public class TestCase : TestCaseBase { [TestCase] public void Execute() { Log("Executing the test..."); }
public class TestCase : TestCaseBase { [TestCase] public void Execute() { Log("Executing the test..."); }
Execution started for file: TestCase.cs
[Info] IBeforeAfterRunExamples execution started
[Info] Execution started for TestCase.cs
[Info] Executing the test...
[Info] Test TestCase.cs finished with no exception.
[Info] IBeforeAfterRunExamples execution ended in: 00:00:00
Execution started for file: TestCase.cs
[Info] IBeforeAfterRunExamples execution started
[Info] Execution started for TestCase.cs
[Info] Executing the test...
[Info] Test TestCase.cs finished with no exception.
[Info] IBeforeAfterRunExamples execution ended in: 00:00:00
CodedWorkflow
partial class, that any other coded test case or
coded workflow inside your project can inherit. This implementation applies to all
coded test cases and coded workflows within your project.
- Create a code source file, and
name it differently than
CodedWorkflow.cs
, otherwise the partial class will have a conflict with the existentCodedWorkflow
read-only class. - Construct a partial class that implements the custom interface for Before and After contexts.
- Rename the class to
CodedWorkflow
. Otherwise, you won't be able to use the available services. - Make sure the class within your
coded source file inherits the
CodedWorkflowBase
class. - Add the
UiPath.CodedWorkflows
namespace at the start of your code source file.using System; using System.Collections.Generic; using UiPath.CodedWorkflows;
using System; using System.Collections.Generic; using UiPath.CodedWorkflows; - Within the class of your code
source file, include
IBeforeAfterRun
.namespace TestAutomationProject1 { public partial class CodedWorkflow : CodedWorkflowBase, IBeforeAfterRun
namespace TestAutomationProject1 { public partial class CodedWorkflow : CodedWorkflowBase, IBeforeAfterRun - Hover over
IBeforeAfterRun
and select Show potential fixes, or select it and pressCtrl + .
. - Select Implement
interface.
This creates the default implementation below:
public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); }
public void After(AfterRunContext context) { throw new NotImplementedException(); } public void Before(BeforeRunContext context) { throw new NotImplementedException(); } - Optionally, you can further
customize the interface, according to your use case. In the code sample below,
the context prints out a message before the execution and after the execution,
it checks if any exception was thrown and prints it out
again.
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }
public void After(AfterRunContext context) { if (context.Exception != null) { Log(context.Exception.Message); } } public void Before(BeforeRunContext context) { Log("this is before"); }