A while ago, I wrote a blog post about Azure Functions integration testing with Mountebank and another blog post about end-to-end (E2E) testing for Azure Functions. In the post, I suggested deploying the Azure Functions app first before running the E2E testing. What if you can run the Azure Function app locally within the build pipeline? Then you can get the test result even before the app deployment, which may result in the fail-fast concept.
Throughout this post, I'm going to discuss how to run a function app locally within the build pipeline then run the integration testing scenarios instead of running the E2E testing after the app deployment.
You can find the sample code used in this post at this GitHub repository:
Here's the straightforward Azure Function app code. I'm using the Azure Functions OpenAPI extension in this app. It has only one endpoint like below:
Run this function app and go to the URL,
http://localhost:7071/api/openapi/v3.json, and you will see the following OpenAPI document.
At this stage, my focus is to make sure whether the OpenAPI document is correct or not. As you can see the OpenAPI document above, the document has a very simple data structure under the
components.schemas.greeting node. What if the data type is complex? We need confirmation. In this case, should we deploy the app to Azure and run the endpoint over there? Maybe or maybe not.
But this time, let's run the app in the build pipeline and test it there, rather than deploying it to Azure.
In order to test the Azure Functions app locally, it should be running on the local machine, using the Azure Functions CLI.
But the issue of this CLI doesn't offer a way to run the app as a background process, something like
func start --background. Therefore, instead of relying on the CLI, we should use the shell command. So, for example, if you use the bash shell, run this
func start & command first, then run
If you use PowerShell, use the
Start-Process cmdlet with the
-NoNewWindow switch so that the function app runs as a background process.
Once the function app is running, execute this bash command on the same console session,
curl http://localhost:7071/api/openapi/v3.json. Alternatively, use the PowerShell cmdlet
Invoke-RestMethod -Method Get -Uri http://localhost:7071/api/openapi/v3.json to get the OpenAPI document.
As we've got the function app running in the background, we can now write the test codes on top of that. So let's have a look at the code below. First, it sends a GET request to the endpoint,
http://localhost:7071/api/openapi/v3.json, gets the response as a string and deserialises it to
OpenApiDocument, and finally asserts the results whether it's expected or not.
As you can see from the test codes above, there's no mocking. Instead, we just use the actual endpoint running on the local machine.
Once the test codes are ready, run the following command:
You will get the test results.
We knew how to run the function app as a background process and got the test codes. Our CI/CD pipeline should be able to execute this. Let's have a look at the GitHub Actions workflow. Some actions are omitted for brevity.
It really depends on the situation, but I'm assuming we should test the code on all the operating systems – Windows, Mac and Linux. In this case, use the
GitHub-hosted runners don't have the Azure Functions CLI installed by default. Therefore, you should install it by yourself.
Install the .NET Core 3.1 SDK as well.
After all the tools are installed, testing should be followed.
The following action is for Mac and Linux runners. The first step is to run the function app as a background process. Although you can simply use the command
func start, this action declares
func @("start","--verbose","false") to minimise the noise from the local debugging log messages.
On the other hand, the following action is for Windows runner. The main difference from the other action is that this time doesn't use the
func command but the
$func variable. Using the
func command will get the error like
This command cannot be run due to the error: %1 is not a valid Win32 application.. It's because the
func command points to the
func.ps1 file, which is the PowerShell script. Instead of using this PowerShell script, you need to call
func.cmd to run the function app as a background process.
Once all the GitHub Actions workflow is set, push your codes to GitHub. Then you'll see all the build pipeline works as expected.
So far, we've walked through how to run the integration testing codes for Azure Functions app within the GitHub Actions workflow, using Azure Functions CLI as a background process. As a result, you can now avoid extra steps for the app deployment to Azure for testing.