Running a Test

The TestRunner.TriggerWorkflow() method is used to run a test. The method creates a HTTP request for the workflow trigger and sends it to the workflow. This example uses HTTP POST but other HTTP methods can be used:

HttpResponseMessage workflowResponse = testRunner.TriggerWorkflow(FunctionToGetTriggerContent(), HttpMethod.Post);

The testing framework will automatically replace a non-HTTP trigger with a HTTP trigger so that the workflow can be started using a HTTP request.

The TriggerWorkflow() method will complete when the workflow execution has completed.

There are a few overloads of the TriggerWorkflow() method that allow you to set the following:

• HTTP request headers.
• URL query parameters.
• The relative path, if the HTTP trigger is configured to use a relative path. The relative path must be URL-encoded by the test case, this is not done by the test runner.

The trigger URL for the workflow is logged to the test execution log. This example is for a workflow that uses a relative path of /thisIsMyContainer/thisIsMyBlob:

Workflow trigger:
    Name: manual
    URL: POST http://localhost:7071/api/stateless-test-workflow/triggers/manual/invoke/thisIsMyContainer/thisIsMyBlob?api-version=2022-05-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=123ao4DL03l1c1C-KRqfsl9hr0G_ipOjg_h77STbAWQ

The example shows a trigger with the name of manual, but the testing framework makes no assumptions about the name of the trigger, it can be set to any valid value.

Test Behaviour when Triggering a Workflow

The behaviour of the TestRunner.TriggerWorkflow() method, and the response from the method, depends on the workflow definition and the configuration of Asynchronous Response Processing, as follows:

Workflow Scenario	Async Response Processing enabled?	TriggerWorkflow() response	Notes
HTTP Trigger and a synchronous Response action	n/a	The response created by the synchronous Response action
HTTP Trigger and an asynchronous Response action	yes	The response created by the asynchronous Response action	The testing framework automatically receives the synchronous HTTP 202 (Accepted) response from the HTTP trigger and uses the callback URL (as defined in the Location header) to poll the workflow for the asynchronous response. It is this asynchronous response that is returned.
HTTP Trigger and an asynchronous Response action	no	The automatic response created by the HTTP trigger	The testing framework automatically receives the synchronous HTTP 202 (Accepted) response from the HTTP trigger and it is this response that is returned. The callback is ignored.
HTTP Trigger and no Response action	n/a	The automatic response created by the HTTP trigger	The testing framework receives a synchronous HTTP 202 (Accepted) response from the HTTP trigger and it is this response that is returned.
A non-HTTP trigger	n/a	The automatic response created by the HTTP trigger that replaces the non-HTTP trigger	The testing framework replaces a non-HTTP trigger with a HTTP trigger, but a matching Response action is not added to the workflow definition. As above, the framework receives a synchronous HTTP 202 (Accepted) response from the HTTP trigger and it is this response that is returned.

In all scenarios the TriggerWorkflow() method will only complete when the workflow execution has completed. If the Response action is followed by other actions, the TriggerWorkflow() method will complete only when the other actions have completed (or been skipped). The TriggerWorkflow() method will wait for the workflow completion up to a maximum period of time, as defined (in seconds) by the runner.maxWorkflowExecutionDuration configuration option in testConfiguration.json. If this option is is not set, the default period of time is 300 seconds, or 5 minutes.

Enabling Asynchronous Response Processing

Asynchronous Response Processing for a test case is disabled by default. It is enabled by calling the TestRunner.WaitForAsynchronousResponse() method:

using (ITestRunner testRunner = CreateTestRunner())
{
    // Configure async response handling in seconds
    testRunner.WaitForAsynchronousResponse(30);

The parameter indicates how many seconds the testing framework should wait for the asynchronous response to be generated by the workflow. A method overload allows the wait period to be expressed as a TimeSpan:

using (ITestRunner testRunner = CreateTestRunner())
{
    // Configure async response handling as a TimeSpan
    testRunner.WaitForAsynchronousResponse(new TimeSpan(0, 2, 0);

If Asynchronous Response Processing is enabled, the workflow callback URL is logged to the test execution log:

Workflow async callback:
    URL: GET http://localhost:7071/runtime/webhooks/workflow/scaleUnits/prod-00/workflows/bc2509cb08ce4d58b04105ef4ab7e178/runs/08585159864168441072386309873CU00/operations/4ac870fc-b315-4f68-a047-5c4a54ab7464?api-version=2022-05-01&sp=%2Fruns%2F08585159864168441072386309873CU00%2Foperations%2F4ac870fc-b315-4f68-a047-5c4a54ab7464%2Fread&sv=1.0&sig=nmRM8486HP5vmGFjKUMh4HQucVMzDTQRPk62
    Timeout for receipt of async response: 30 seconds