86129f01-af29-454c-afcc-dccd7bf9d1c7.jpg

Senior RPA Developer

This solution is made to be used by UiPath developers to help them write better code and save them a lot of time when change requests occur.

  

There are **four main parts** to this project:

1.  Framework used for automated running of unit tests and logging.
2.  GUI specifically coded for this framework.
3.  Custom activity package that plays essential part in running of Framework and Unit Tests both.
4.  Unit Test Template used to easily make Framework ready unit tests.  
    

My main inspiration was to help myself and other developers save time and effort that manual testing regularily takes, and which can be solved through automation (after all, we are automating processes, so why not a part of the development also?).

Tired of testing workflows manually? This framework for running unit tests will help ease the development and save time.

Tired of testing workflows manually? This framework for running unit tests will help ease the development and save time

This assembly consists of three core parts:

\* It contains custom \*\*Assert Unit Test\*\* activity that must be used when making \*\*Unit Tests\*\*.

\* \*\*Assert Unit Test\*\* activity is used as a container for writing \*\*Assert methods\*\* ([imported](https://studio.uipath.com/docs/importing-new-namespaces) from \_CustomActivities.VariableComparer\_ namespace) which are used to evaluate unit test outputs.

\* Assert.AreEqual(expected,actual) - contains method overloads that are used to check if the compared variables contain the exact same values.

\* Assert.AreNotEqual(expected,actual) - contains method overloads that are used to check if the compared variables doesn't contain the exact same values.

\* Assert.AreSame(expected,actual) - contains method overloads that are used to check if the compared variables reference the same object in memory.

\* Assert.AreNotSame(expected,actual) - contains method overloads that are used to check if the compared variables doesn't reference the same object in memory.

\* Assert.Contains(item, target) - contains method overloads that are used to check if the item is contained inside of the target object.

\* Assert.NotContains(expected,actual) - contains method overloads that are used to check if the item is not contained inside of the target object.

\* Assert.IsNull(actual) - checks if variable is referencing null object

\* Assert.IsNotNull(actual) - checks if variable is not referencing null object

\* \*\*Assert methods\*\* throw custom exceptions that are used by the \*\*Framework\*\* to log test results and give important information in case of a test failiure.

\* AssertException is main exception thrown by Assert methods.

\* AssertNullException is exception thrown when Assert.IsNull or Assert.IsNotNull method returns false.

\* CustomAssertException is generic exception that is thrown when random boolean expression that returns false is passed to Assert Unit Test activity

  

**Quick guide:**

\* Install this package using \[[Package manager](https://studio.uipath.com/docs/managing-activities-packages#section-managing-packages)\]

\* \[[Import](https://studio.uipath.com/docs/importing-new-namespaces)\] \_CustomActivities.VariableComparer\_ namespace in your workflow

\* In Activities side-bar search for Assert Unit Test activity

\* Use Assert Unit Test activity to write any of the above Assert methods (e.g. Assert.AreEqual(var1,var2))

Custom activity for comparing variables to be used with UiPath Testing Framework

GUI made to be used with [Testing Framework for UiPath](https://marketplace.uipath.com/listings/uipath-testing-framework?searchId=d7feaf46-4912-4137-95d2-8cc68f964ab8).

  

The GUI serves multiple purposes:

*   **Selecting which tests to run** - it reads all the tests found in **Tests\_Repository** folder and its subfolders.
*   **Showing the test results.**
*   **Allowing multiple test runs** during single \_RunAllTests.xaml\_ execution.

GUI used for Testing Framework for UiPath.

GUI made to be used with [Testing Framework for UiPath](https://go.uipath.com/component/uipath-testing-framework).

GUI serves multiple purposes:

*   Selecting which tests to run - GUI reads all the tests found in **Tests\_Repository** folder and its subfolders.
*   Showing the test results
*   Allowing multiple test runs during single \_RunAllTests.xaml\_ execution

GUI used for the UiPath Testing Framework

When you design and develop enterprise level automations with **UiPath** it is extremely important to write a clean, maintainable code. For that developers have to write large number of workflows, each having a single responsibility.

  

But this comes at a price. Developers need to choose how they will pass the data between workflows, and there are only two options to choose from:

  

1\. Make many input arguments

2\. Pass a single input argument of Dictionary type

  

Both of these options have flaws.

  

· First option is better from **Single Responsibility Principle** and **Testing** standpoint, but wastes a huge amount of developer’s time, and makes development such a tedious process. Especially when pressure on the project is high, it usually makes developers stop caring about clean code.  Workflows become big and they perform many things.

· Second option makes development faster by passing only a few arguments, but makes writing **tests** tedious. More importantly, it is very easy to make **a typing mistake** when calling specific values by string keys, which again increases debugging time. And worst of all, requires good planning for bigger development teams (Dev A that defines the dictionary needs to let Dev B know about the key names).

  

Now, what if we could have best of both worlds?

  

The solution to this problem is good old **POCO**s (plain old CLR objects) -&gt; .NET classes that carry plain data.

  

Wouldn’t it be great if we could define class models in C# or VB.NET and just integrate these new classes into an UiPath project, and get all the goodies that come with intellisense (no more typos with _Dictionaries_, _JObjects_, _XmlElements_)?

  

Also, don’t you hate when working with REST API that you have to parse that huge JSON response into smaller variables or a dictionary or in the worst case pass that huge JObject around?

  

Not only this, wouldn’t it be great if we could define interfaces, and leverage all the OOP (Object Oriented Programming) concepts to make better, cleaner and maintainable code?

  

**GenerateModelsFromSourceFiles** custom activity enables you to do just that.

Custom activity which allows developers to easily integrate classes and interfaces into UiPath, simply by writing plain text source files (.cs or .vb).

ユーザー情報