LogicAppUnit is a testing framework that simplifies the creation of automated unit tests for Standard Logic Apps running in a local development environment, or in a build server as part of a DevOps pipeline. Standard Logic Apps do not include an out-of-the-box testing capability and this framework has been designed to fill this gap. The framework is based on the Logic Apps Sample Test Framework that was developed by Henry Liu, and includes additional functionality to make it easier to author and run tests and validate (assert) the results.

The framework does not support the testing of:

• Consumption Logic App workflows.
• Standard Logic App workflows that have been deployed to Azure.

The testing framework has been designed to make it easier to perform isolated unit testing of a workflow. The framework does this by modifying a copy of the workflow definition to remove the dependencies on external services and APIs, without affecting the functionality or behaviour of the workflow. This means that workflows can be easily tested in a developer's local environment, and by a DevOps pipeline running on a build server, where there is no access to Azure services or any other workflow dependencies.

• Replace non-HTTP triggers with HTTP triggers to enable automated testing of every workflow, irrespective of the trigger type.
• Remove external service dependencies for built-in service provider connectors by replacing these actions with HTTP actions and a mock HTTP server that is managed by the framework.
• Remove dependencies on invoked workflows by replacing the Invoke Workflow actions with HTTP actions and a mock HTTP server that is managed by the framework.
• Remove external service dependencies for managed API connectors by automatically re-configuring managed API connections to use a mock HTTP server that is managed by the framework.
• Remove all retry policies to ensure that tests exercising failure scenarios do not take a long time to execute.
• Detailed logging to help with workflow test authoring and debugging.
• Programmatic access to the workflow run history to enable assertion of workflow run status, response status, action status, input and output messages and more. This includes support for action repetitions inside a loop.
• Programmatic access to the requests sent to the mock HTTP server to enable assertion of the data sent from the workflow to external services and APIs.
• Override specific local settings for a test case to enable more testing scenarios (e.g. feature flags).
• Automatically enable run history for stateless workflows by creating the Workflows.<workflow name>.OperationOptions setting.

This code repository includes three projects:

Download the LogicAppUnit testing framework package from nuget: https://www.nuget.org/packages/LogicAppUnit/

The framework has been tested with these environments:

• Windows
• Linux (Ubuntu)
• MacOS

• Mark Abrams
• Sanket Borhade
• Shadhaj Kumar

The best way to understand how the framework works and how to write tests using it is to read the wiki and look at the example tests in the LogicAppUnit.Samples.LogicApps.Tests project.

This is a list of possible future improvements and changes for the framework. Please create a new issue if there are other features that you would like to see.

• Improve the creation of the mocked responses using the mock HTTP server.
  • The current approach is to use a delgate function that takes a HttpRequestMessage as an input and returns a HttpResponseMessage, where the delegate function creates a response message based on the request message and the requirements of the test case. This can be improved by including a fluent API to match requests and build responses, similar to that used by WireMock.net. A fluent API is more intuitive and easier to use for a test author.
  • The proposed solution will work with the existing delegate function, such that if a request is not matched by any request matcher defined in the fluent API, the delegate function will be called, if it is configured.
• Allow mocked responses to be created in a test class's Initialize step, these responses would then be automatically configured for all tests within the test class. This would remove the need to repeatedly configure the same mocked responses in multiple tests.
• Add a test configuration option to allow the port number for the mock HTTP server to be changed from the default of 7075.