LogicAppUnit Testing Framework:
- The testing of workflows that call in-line C# is now supported. The .csx script files are copied to the test working directory and are not mocked. [PR #35, @sschutten]
- Added a new configuration option
workflow.managedApisToMock
in thetestConfiguration.json
file to control which Managed API connectors are mocked. If this configuration is not set, all Managed API connectors are mocked - this ensures backwards compatabiity with previous versions. [PR #38, @zzznz27]
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
call-data-mapper-workflow
workflow and unit tests to test workflows that call the data mapper. - Added a
inline-script-workflow
workflow and unit tests to test workflows that call in-line C# script (.csx) files.
LogicAppUnit Testing Framework:
- Improved the logging when using the Fluent API to match requests based on request headers or query parameters. When the actual and expected header or query parameter values do not match, both values are logged to make it easier to diagnose any test issues. Previous versions of the framework logged the match failure but did not log the actual and expected values.
- Added
IMockRequestMatcher.FromAction(string[] actionNames)
to allow a mock request matcher to match a request based on the name of the workflow action that created the request. This feature depends on thex-ms-workflow-operation-name
header being present in the request. Refer to the wiki for details of when the Logic App runtime creates this header. - Retry policies for actions using a managed API connection are removed and replaced with a
none
policy. This is the same pre-processing that is applied to HTTP actions. Previous versions of the framework did not remove the retry policies for actions using a managed API connection which meant that tests could take a long time to complete if they were testing failure scenarios. - The framework checks the
connections.json
file and will fail a test if there are any managed API connections that are configured using theManagedServiceIdentity
authentication type. The Logic Apps runtime only supports theRaw
andActiveDirectoryOAuth
authentication types when running in a local developer environment. [Issue #30] - The
testConfiguration.json
file is now optional. If the file does not exist, or contains an empty JSON document ({}
), the default values are used for all settings. Previous versions of the framework would fail a test if the configuration file did not exist. [Issue #28] Call a local function
actions are now mocked using HTTP actions. This means that the dependencies between a workflow and a .NET Framework function can be broken to enable better unit testing of the workflow.- Added
IMockResponseBuilder.ThrowsException(Exception exceptionToThrow)
to simulate an exception being thrown by a local .NET Framework function. - Fixed a typo in the name of the
logging.writeFunctionRuntimeStartupLogs
configuration setting. Previously the setting was namedlogging.writeFunctionRuntineStartupLogs
(note the incorrect spellingRuntine
). [PR #29, @jeanpaulsmit]
⚠️ This is a breaking change. Any use of thewriteFunctionRuntineStartupLogs
setting in thetestConfiguration.json
file will need to be updated.
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
call-local-function-workflow
workflow and unit tests to demonstrate the mocking of a local .NET Framework function.
LogicAppUnit Testing Framework:
- Added new properties
TestRunner.WorkflowWasTerminated
,TestRunner.WorkflowTerminationCode
andTestRunner.WorkflowTerminationMessage
to allow the effects of a Terminate action in a workflow to be tested. - Mock responses can be configured using the fluent API in the test class initialization method, using the
WorkflowTestBase.AddMockResponse()
method. Mock responses configured using this method will be used by every test runner that is created in the same test class, and have a lower priority compared to the mock responses created usingITestRunner.AddMockResponse()
andITestRunner.AddApiMocks
. This feature removes the need to repeatedly configure the same mocked responses in multiple tests in a test class. - The HTTP status code for the default mock response can now be set in the
testConfiguration.json
file using therunner.defaultHttpResponseStatusCode
option. Previously the status code was hard-coded to HTTP 200 (OK). The default value for this option is HTTP 200 (OK) to ensure backwards compatibility. - Added a new feature to remove the chunking configuration for HTTP actions (
runtimeConfiguration.contentTransfer.transferMode
). This feature is enabled/disabled in thetestConfiguration.json
file using theworkflow.removeHttpChunkingConfiguration
option. The default value for this option istrue
. [Issue #24] - Added
IMockResponseBuilder.WithAccepted()
as a short-cut when creating a response with a HTTP 202 (Accepted) status code.
LogicAppUnit Testing Framework:
- Mock responses can be configured using
ITestRunner.AddMockResponse()
and a fluent API, this includes the definition of the request matching conditions and the response. - Removed public methods
ContentHelper.SerializeObject()
,ContentHelper.DeserializeObject()
andContentHelper.JClone()
, these were for internal use only and are now obsolete. - Include the LogicAppUnit version at the end of the test log.
- The maximum execution time for a workflow can now be set in the
testConfiguration.json
file using therunner.maxWorkflowExecutionDuration
option. Previously this duration was hard-coded to 5 minutes. The default value for this option is 300 seconds (5 minutes). - Improved the logic that locates the Azure Functions runtime executable (
func.exe
) when running on a Windows platform. Previous versions of the framework used the PATH environment variable in theMachine
scope which caused issues when tests were running in an Azure DevOps pipeline (because theFuncToolsInstaller@0
task adds the path forfunc.exe
to the PATH environment variable in theProcess
scope). Now the framework combines the PATH environment variables for theMachine
,Process
andUser
scopes to ensure that all possible paths are checked. [PR #20, @AlexanderDobrescu and PR #21, @danielduartemindera]
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
fluent-workflow
workflow and unit tests to demonstrate the use of the fluent API.
LogicAppUnit Testing Framework:
- Added support for Linux and MacOS platforms. [PR #14, @easchi and PR #15, @atthevergeof]
- Added new overloads to
TestRunner.TriggerWorkflow()
to configure URL query parameters when triggering a workflow with a HTTP trigger. [PR #15, @atthevergeof] - Added support for workflows using a HTTP trigger with an asynchronous response. Previous versions of the framework assumed that all responses were synchronous. Now the framework handles a 202 (Accepted) response and uses the callback URL (in the
Location
header) to poll the workflow and get the response. [PR #15, @atthevergeof] - Added support for workflows using a HTTP trigger where the response action is not the last action in the workflow. Previous versions of the framework assumed that the workflow was complete once the response was received. Now the framework polls the workflow status to ensure that the workflow has completed. [PR #15, @atthevergeof]
- Fixed a bug in
TestRunner.TriggerWorkflow()
where the return value was being incorrectly set to the (disposed) workflow run history API response. The response is now correctly set to the workflow trigger API response. This bug only occurred for workflows that have a non-HTTP trigger (which is then replaced by a HTTP trigger by the framework).
⚠️ This is a breaking change. Previously the status code for the response would have been HTTP 200 (OK), now it will be HTTP 202 (Accepted).
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
http-async-workflow
workflow and unit tests to demonstrate the use of the testing framework with HTTP triggers and asynchronous responses.
LogicAppUnit Testing Framework:
- Invoked child workflows are now mocked using HTTP actions. This means that the dependencies between a parent workflow and child workflows can be broken to enable better unit testing of the parent workflow.
LogicAppUnit.TestRunner
does not assume that the name of the HTTP trigger ismanual
, it now retrieves the name from the workflow definition.- This change is needed because the new Standard Logic App designer allows a developer to edit the name of the HTTP trigger. In all previous versions of the designer the trigger name was set to
manual
and could not be changed.
- This change is needed because the new Standard Logic App designer allows a developer to edit the name of the HTTP trigger. In all previous versions of the designer the trigger name was set to
- Non-HTTP triggers that are replaced with HTTP triggers now have the same name as the original trigger. Previously, the name of the HTTP trigger was set to
manual
.
LogicAppUnit.Samples.LogicApps.Tests:
- Added an
invoke-workflow
workflow and unit tests to demonstrate the use of the testing framework with child workflows that are invoked from a parent workflow.
LogicAppUnit Testing Framework:
- Changed the logic that updates the
connectionRuntimeUrl
for Managed API connectors so that it works with URL values that include@appsetting()
references. [Issue #9]
LogicAppUnit Testing Framework:
- Added methods to
LogicAppUnit.TestRunner
to allow tests to access the tracked properties that are created by an action. This includes action repetitions.- This is only available for stateful workflows because tracked properties are never recorded in the run history for stateless workflows.
- Updated
LogicAppUnit.Helper.ContentHelper.FormatJson(string)
so that any references to the local server name are replaced withlocalhost
.
LogicAppUnit.Samples.LogicApps.Tests:
- Updated the
http-workflow
workflow and unit tests to include tracked properties.
LogicAppUnit Testing Framework:
- Added methods to
LogicAppUnit.TestRunner
to allow tests to assert actions that run in anUntil
loop or aForEach
loop. These actions are known as action repetitions. - Added methods to
LogicAppUnit.TestRunner
to allow tests to access the input and output messages for an action. This includes action repetitions. - Added an interface
LogicAppUnit.ITestRunner
and updatedLogicAppUnit.TestRunner
to implement this interface. This interface has been added to allow for the implementation of other test runners in the future. - Method
LogicAppUnit.WorkflowTestBase.CreateTestRunner()
returns an instance ofLogicAppUnit.ITestRunner
and notLogicAppUnit.TestRunner
.
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
loop-workflow
workflow and unit tests to demonstrate the use of the testing framework with a workflow containing actions in anUntil
loop and aForEach
loop.
LogicAppUnit Testing Framework:
- Changed the visibility of the
LogicAppUnit.Hosting
classes frompublic
tointernal
. These classes are not for use by test authors. - Added a new configuration option
azurite.enableAzuritePortCheck
totestConfiguration.json
to enable or disable the Azurite port checks. - Refactored the internal classes that update the workflow definition, local settings and connection files.
- The Test Runner (
LogicAppUnit.TestRunner
) now supports workflow HTTP triggers with relative paths. - Improved handling of stateless workflows:
- Added a new configuration option
workflow.autoConfigureWithStatelessRunHistory
totestConfiguration.json
to control whether the testing framework automatically configures the workflowOperationOptions
setting toWithStatelessRunHistory
. If this option is not set for stateless workflows, the workflow run history is not stored. The default value for this configuration option istrue
. - If a stateless workflow is tested and the
OperationOptions
setting is not set toWithStatelessRunHistory
, andworkflow.autoConfigureWithStatelessRunHistory
is set tofalse
, the test fails with aTestException
error.
- Added a new configuration option
- Added the
TestRunner.WorkflowClientTrackingId
property so that tests can assert a workflow's client tracking id. - Improvements to
Readme.md
.
LogicAppUnit.Samples.LogicApps.Tests:
- Added a
stateless-workflow
workflow and unit tests to demonstrate the use of the testing framework with a stateless workflow, a custom client tracking id and a relative path configured in the HTTP trigger.
- Initial version.