Coded Test Case

Coded test cases automate and validate application behavior in a structured manner. They are similar to low-code test cases and allow for flexible automation using code.

When you create a coded test case, you define a Given-When-Then structure. This structure consists of three phases:

1. Arrange - The arrange phase prepares the application.
2. Act - The act phase performs specific actions.
3. Assert - The assert phase verifies the expected results.

Coded test cases can also invoke other low-code workflows or test cases, allowing code reuse. This integration enables the creation of flexible test scenarios.

You can apply execution templates for Coded test cases, as well. Visit Execution Templates to learn how to work with execution templates.

Structure

Coded automations feature a structured design with namespaces, helper classes, and entry point methods. The framework of coded automations allows you to write the automations using the C# programming language.

Follow the detailed structure of a coded automation as described in the following sections.

When you create a coded automation, a namespace is automatically generated using the name of the Studio project. For instance, if your Studio project is named "My project", the namespace for all coded automations will be "Myproject".

Additionally, if you create a coded automation inside a folder in your Studio project, then the namespace will be the name of the project and the name of the folder. For instance, if your Studio project is named "My project", and the folder is named "place", then the namespace will be "Myproject.place".

Both coded workflow and coded test case automations use the CodedWorkflow partial class from the UiPath.CodedWorkflows package. This class gives the automation access to necessary interfaces for services (equal to activity packages), based on the installed activity packages in your project.

Note: The UiPath.CodedWorkflows package is automatically included when you import an activity package that supports coded automations, such as UiPath.System.Activities 23.10 or higher.

CodedWorkflow

Coded automations inherit the CodedWorkflow partial class, creating a relationship of type CodedAutomationExample : CodedWorkflow. This means that the CodedAutomationExample class inherits attributes, methods, and functionality from the CodedWorkflow class. Essentially, it can access and utilize the features defined in the CodedWorkflow class, which provides a foundation for the coded automation, making it easier to build upon and customize the automation's behavior.

The CodedWorkflow class is declared as a partial class, allowing you to extend its functionalities by defining the same partial CodedWorkflow class in a code source file. This way, you can add new fields and methods to further customize the behavior of your coded automations. You can use this approach to implement a Before and After interface, specifically for coded test cases.

Additionally, the CodedWorkflow partial class inherits the CodedWorkflowBase class.

CodedWorkflowBase

The CodedWorkflowBase class holds the built-in functionalities that a coded automation inherits. This class contains methods and specific properties for managing workflow instances, runtime access, handling service containers, and configuring environment contexts. The CodedWorkflowBase class also offers another separate method for logging that you can customize yourself.

Note: In the Code Editor Settings, select Enable Source Decompilation to view the CodedWorkflowBase class.

Check out the CodedWorkflowBase methods in the table below:

Method	Description
ICodedWorkflowServices services Note: We recommend you to use the the Log, BuildClient, and RunWorkflow methods through the services class and their corresponding services, instead of using them as standalone, readily available methods.	Provides access to the available services for coded workflows, such as: OutputLoggerService: Allows you to output logs, using the Log method. OrchestratorClientService (the BuildClient method): Allows you to enable the interaction with Orchestrator, through the BuildClient method. WorkflowInvocationService: Allows you to invoke other workflows, using the RunWorkflow method. Container: The container where all the services are stored. Allows you to manage resources for coded workflows, handling automatic import of namespaces and types, using the AutoImportedNamespaces and AutoImportedTypes methods. Additionally, it provides an instance of a specific service, using the Resolve method.
serviceContainer(ICodedWorkflowServiceContainer) Note: This has been replaced by ICodedWorkflowServices services . If you continue to use this syntax, you get a warning pointing you to use the new services.Container syntax.	Provides access to the dependency injection container that is specific to the current coded workflow. This container, known as the service container, allows you to retrieve instances of services that have been registered within it.
GetRunningJobInformation()	Retrieves information about the currently running job within the context of the coded workflow. The method accesses the RunningJobInformation property of the executorRuntime object, that holds information about job status, progress, parameters, and timestamps.
Log(string message, LogLevel level = LogLevel.Info, IDictionary<string, object>additionalLogFields = null)	Adds additional log fields to log messages with specified attributes.
RunWorkflow(string workflowFilePath,IDictionary<string, object> inputArguments = null,TimeSpan? timeout = null, bool isolated = false, InvokeTargetSession targetSession = InvokeTargetSession.Current)	Provides a structure to execute a workflow within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments.
RunWorkflowAsync(string workflowFilePath,IDictionary<string, object> inputArguments = null, TimeSpan?timeout = null, bool isolated = false, InvokeTargetSession targetSession = InvokeTargetSession.Current)	Provides a structure to execute a workflow asynchronously within the context of the given workflow runtime. It can set parameters, handle potential isolation, and initiate workflow execution. The returned task provides the results of the executed workflow, including its output and input/output arguments.
DelayAsync(TimeSpan time) and DelayAsync(int delayMs)	Suspends execution for a specified period of time asynchronously.
Delay(TimeSpan time) and Delay(int delayMs)	Suspends execution for a specified period of time.
HttpClient BuildClient(string scope = "Orchestrator", bool force = true)	Builds an HTTP client with a specified scope and access token.
RegisterServices(ICodedWorkflowsServiceLocator serviceLocator)	Registers services (activity packages) to the coded workflow's service locator. You can override it when you want to inject custom services into the dependency injection container. Learn how to create and use custom services (coded activity packages) here.

The entry point method for both coded workflows and coded test cases is named Execute() and is attributed as either Workflow or TestCase. You can change the name of the method, as long as you attribute it to either Workflow or TestCase.

You can only use one Execute() method ([TestCase] or [Workflow]) inside a file, that inherits the Coded Workflowclass.

In this method, you can add input and/or output arguments, which are equivalent to In, Out or In/Out arguments in low-code automations. Go through the Working with Input and Output arguments tutorial to learn how to use arguments in coded automations.

This entry point method serves as the starting point for running the automations. This makes coded workflows and test cases easy to identify as entry points due to their Execute() method.

Project compatibility

You can use Coded automations only in Windows and Cross-platform projects.