An Approach how to Implement Unit Tests in UiPath

News Tutorials
, ,
1

For some time now I have been working on the topic of how unit tests can be implemented in UiPath. Unit tests are very important elements in automation for me. In my case I want to realize manual executed black-box tests, to ensure that my automations deliver the expected result. I look at this from the perspective of an RPA developer who is in the development process.

Here an example: I have a Main process which invokes an SAP BAPI call. Here I add an empty sequence.

image

In the next step I rename the sequence activity to Unit Test and a name that is as self-explanatory as possible.

image

Now I extract the empty sequence as a workflow. The call to the workflow in the main routine is deleted so that the unit test exists independently in the project.

image

image

In this extracted workflow I add the module under test. Also I add a few verify with operator activities from the UiPath Testing Package. With this I created an image of the call from the main routine.

image
image587Ă—514 17.5 KB

The import arguments are fixed and the export arguments are verified.

image

image

The advantage of this approach is that this kind of unit tests can be repeated at any time with the same inputs and the same expected outputs. They are part of the automation workflow, but independent of it, because they can only be called manually. The implementing of unit tests promotes the modularization of the automation workflows. A test-driven development can be realized on this way in the Studio.

Even though this approach seems a bit cumbersome and a bit handmade, it does the job and gives me as an RPA developer reliability in the automation workflows I create.

13 Likes
2

@StefanSchnell

This is a very interesting post and I’m surprised it hasn’t gotten a lot of attention. What is more important than testing your own code? Two questions:

  1. Is there a difference between extracting the empty sequence as a workflow and simply creating a new sequence/workflow?
  2. I can see how this approach would handle functional testing by passing the invoked workflow a few positive and negative tests, but how can you streamline the process of testing the invoked workflows ability to handle exceptions? That is, force the invoked workflow to throw an exception and see if it gets bubbled up correctly to the calling code. Of course, this gets even worse if your invoked xaml is itself invoking another xaml. Right now I do this all manually and it is quite time consuming.
1 Like
3

@tsverthoff

Hi,
thanks for your post.
Now to your questions:

  1. As far as I can see there are no differences.

  2. In my opinion should the scenario that you describe realize with this approach. But it depends on your workflows which you call. If these can trigger unhandled exceptions this occurs an error. It is necessary to use Try-Catch and the ContinueOnError in this workflows. However, I’m afraid that this approach can’t really help minimize the manual programming effort here. If you have requirements in this, perhaps a look at the Test Suite would be helpful. This approach here is only on an “atomic” level.

Best regards
Stefan

4

I think there might be a way to add exception handling tests to a unit test for a workflow.

  1. The unit test workflow has a string array. Each string is the type of exception that you want to throw in the workflow under test.
  2. The unit test loops over the string array of exceptions and passes one string at time to the workflow under test as an input argument: in_UNIT-TEST_strExceptionType
  3. The workflow under test has a Switch activity that looks at the string that is passed in through in_UNIT-TEST_strExceptionType. Each case in the Switch activity then throws a specific type of exception.
1 Like
5

@tsverthoff

Hi,

great idea, but I’m not sure if that doesn’t contradict the unit test approach. A unit test must be simple and it should be deliver a clear result. So I am asking myself if it would not be better to create several unit tests. But here again the problem arises, how do you bring together an overall result. Here again an interesting aspect becomes clear. Automation using RPA is another form of programming. Sooner or later, what we know from programming will also be required for RPA. This won’t help you now, but if you have these requirements, check out the Test Suite. In my experience you will otherwise get lost and spend a lot of time maintaining your unit tests.

Best regards
Stefan