In the previous post, Azure Functions Deployment Strategies, we have briefly looked several ways to deploy Azure Functions codes. In this post, I’m going to walk through how we can test Azure Functions codes on developers’ local machine.
Mocking and Asserting on ScriptCs
We need to know how to run test code scripts using ScriptCs. We’re not going too much details how to install ScriptCs here. Instead, we assume that we have ScriptCs installed on our local machine. In order to run test codes, mocking and asserting are crucial. There are ScriptPack NuGet packages for mocking and asserting, called ScriptCs.Moq
and ScriptCs.FluentAssertions
. If we use those packages, we can easily setup unit testing codes, with similar development experiences. Let’s have a look.
First of all, we need to install NuGet packages. Make sure that ScriptCs doesn’t yet support NuGet API version 3 at the moment of this writing, but it will support sooner or later based on their roadmap. In other words, we should stay on NuGet API version 2. This is possible by creating a scriptcs_nuget.config
file in our script folder like:
Then run the command below on our Command Prompt console, to install ScriptCs.Moq
.
Now, create a run.csx
file like:
Run the following command and we’ll be able to see mocked result as expected.
This time, install ScriptCs.FluentAssertions
for assertions.
This is the script for it:
We expected world
but the value was hello
, so we can see the message like:
Now, we know how to run test codes on our local machine using ScriptCs. Let’s move on.
Emulating Azure Functions on ScriptCs
There is no official tooling for Azure Functions running in a developer’s local machine yet. However, there is a script pack called ScriptCs.AzureFunctions
that runs on ScriptCs. With this, we can easily emulate Azure Functions environment on our local dev machine. Therefore, as long as we have a running Azure Functions code, ScriptCs.AzureFunctions
wraps the code and run it within the emulated local environment.
Azure Functions Code with Service Locator Pattern
This is a sample Azure Functions script, run.csx
.
When you look at the code above, you might have found that we use a Service Locator Pattern. This is very important to manage dependencies in Azure Functions. Without a service locator, we can’t properly test Azure Functions codes. In addition to this, Azure Functions only supports a static method so the service locator instance is instantiated with the static
accessor.
Here are the rest bits of the poorman’s service locator pattern.
Emulation Code for Azure Functions
Now, we need to write a test code, test.csx
. Let’s have a look. This is relatively simple.
- Import
run.csx
by using the#load
directive. - Arrange parameters, variables and mocked objects.
- Run the Azure Functions code.
- Checks the expected result.
If we use ScriptCs.FluentAssertions
package here, the last assert part would be much nicer.
Now run the test code:
Now, we have an expected result in the emulated environment.
So far, we’ve briefly walked through how we can emulate Azure Functions on our development environment. For testing, Service Locator Pattern should be considered. With ScriptCs.AzureFunctions
, testing would be easily performed in the emulated environment. Of course this is not a perfect solution but surely it’s working. Therefore, it would be useful until the official tooling is released. If our build server allows ScriptCs environment, this emulation environment can be easily integrated so that we can perform testing within the build and test pipeline.
Comments are closed.