-
Notifications
You must be signed in to change notification settings - Fork 14
Handling Workflow Dependencies
A workflow usually has dependencies on one or more external services. For example, a workflow may read a message from a Service Bus queue using a trigger, or read data from a SQL Server database using a SQL Server connection, or send an email using a SMTP connection. To test a workflow in an isolated environment, these dependencies need to be removed and replaced with something else so that:
- a workflow can be run on demand by the test framework, using different request payloads to test different paths and scenarios in the workflow.
- a connection's inputs can be validated by a test case.
- a connection's outputs can be configured in a test case to simulate specific responses that test different scenarios within the workflow.
And all of this must be done so that the functionality and behaviour of the workflow is not affected.
The testing framework will automatically remove the following dependencies when a workflow is tested:
- Workflow Triggers that use a non-HTTP connector
- Actions that use a Built-In Service Provider Connector
- Actions that use a Managed API Connector
- Invoke Workflow actions that call a child workflow
- Call Local Function actions that call a local function written using the .NET Framework
- External URLs configured in the Settings file
The testing framework will also remove any retry policies for actions to improve the run-time execution time for the tests.
These features are described in the next sections.
- Home
- Using the Testing Framework
- Test Configuration
- Azurite
- Local Settings File
- Test Execution Logs
- Stateless Workflows
- Handling Workflow Dependencies
- Fluent API
- Automated testing using a DevOps pipeline
- Summary of Test Configuration Options
-
Example Mock Requests and Responses
- Call a Local Function action
- Invoke Workflow action
- Built-In Connectors:
- Service Bus
- SMTP
- Storage Account
- SQL Server