Poor man's dependency injection - Mocking without Studio Pro

I’ve been toying with a poor man’s solution to dependency injection/mocking. The goal is to test business logic in isolation without worrying about external dependencies.

I know Studio Pro can do this natively, but I’m not on Pro yet and I know there are others in the same boat.

Curious to hear any feedback…Does this make sense? Is there a better way? What have you done/seen?


The technique is basically this:

  • When you have a dependency that’s hard to test, encapsulate it in a pair of workflows.
    • Workflow 1: A mock
    • Workflow 2: The real implementation
  • Next, in the workflow that needs this dependency:
    • Add an argument.
      • I name it in_DependencyFilename_MyDependency. For example, in_DependencyFilename_GetEmails.
      • The argument’s default value is the filename of the mock.
    • Add an “Invoke Workflow File” activity.
      • The filename you pass the activity is not a hardcoded string but rather your in_DependencyFilename_MyDependency argument.
  • In the workflow that calls the dependency-calling workflow, set in_DependencyFilename_MyDependency to the filename of the real implementation.

Now when you’re debugging, the mock is called by default. In production, the real implementation is called instead.


  • You’re processing Outlook messages.
  • You need to get unread emails, mark them read, and extract attachments.

With/Without Dependency Injection

  • Without: You add a Get Outlook Mail Messages activity to your workflow. Any dev who works on this project now needs an Outlook account to test with. That makes it harder to test the business logic for that flow. If you interact with a lot of third-party services, managing those dependencies can become cumbersome.
  • With: You put Get Outlook Mail Messages inside a separate workflow. Your main workflow calls that workflow or its corresponding mock, depending on the filename argument passed in (injected). The mock reads saved Outlook message files from the filesystem. Now the business logic can be tested in isolation.

Steps for Mocking

  1. Create a workflow named GetEmails.
    1. Move Get Outlook Mail Messages into that workflow.
    2. Have the workflow return the emails via an output argument, out_Emails.
  2. Create a folder named TestEmails in your project folder.
    1. Save some Outlook messages to it.
  3. Create a workflow named GetEmailsMock.
    1. Have it load all emails in the TestEmails folder.
    2. Have it return the loaded emails via an output argument, out_Emails.
  4. Create a workflow named ExtractAttachments.
    1. Create an argument named in_DependencyFilename_GetEmails.
      1. Direction: In
      2. Type: String
      3. Default value: “GetEmailsMock.xaml”
    2. Add an Invoke Workflow File activity.
      1. Filename: in_DependencyFilename_GetEmails
      2. Add an output argument, out_Emails, of the same type as the one in GetEmails/GetEmailsMock.
  5. In your main workflow:
    1. Add an Invoke Workflow File activity.
    2. Set the filename to “ExtractAttachments.xaml”.

When you debug ExtractAttachments, the mock will be called. When you run the whole project, the real workflow will be called.

1 Like

Hello @eeskildsen!

It seems that you have trouble getting an answer to your question in the first 24 hours.
Let us give you a few hints and helpful links.

First, make sure you browsed through our Forum FAQ Beginner’s Guide. It will teach you what should be included in your topic.

You can check out some of our resources directly, see below:

  1. Always search first. It is the best way to quickly find your answer. Check out the image icon for that.
    Clicking the options button will let you set more specific topic search filters, i.e. only the ones with a solution.

  2. Topic that contains most common solutions with example project files can be found here.

  3. Read our official documentation where you can find a lot of information and instructions about each of our products:

  4. Watch the videos on our official YouTube channel for more visual tutorials.

  5. Meet us and our users on our Community Slack and ask your question there.

Hopefully this will let you easily find the solution/information you need. Once you have it, we would be happy if you could share your findings here and mark it as a solution. This will help other users find it in the future.

Thank you for helping us build our UiPath Community!

Cheers from your friendly

I realize this is a really old post, but I just wanted to say I am doing this also and exploring this method for simulating object-oriented design patterns.

You can also think of this in general for managing configurable behavior, where you want to be to have essentially an interface and have an instance passed to the workflow, so it can call the “interface” without knowing about all of those details. It helps make more granular workflows.

1 Like