TL;DR – This series of posts shows how you can integration test Azure Functions projects using the open-source Corvus.SpecFlow.Extensions library and walks through the different ways you can use it in your SpecFlow projects to start and stop function app instances for your scenarios and features.
This is the last in a series of posts. The posts in the series are:
- Using step bindings to start functions
- Using hooks to start functions
- Supplying additional configuration to functions
- Using Corvus.SpecFlow.Extensions in a build pipeline (this post)
In the previous posts in this series, we introduced the Corvus.SpecFlow.Extensions project and showed how you can use the bindings and classes it provides to start functions apps as part of your scenarios and features. We’re going to finish with some pointers on how to ensure these functions can run as part of your build pipelines.
Depending on how your build system works, it’s relatively easy to ensure that tests using these methods are able to run as part of the build pipeline.
If, like us, you’re using Azure DevOps with hosted agents, you’ll need to add a step to your pipeline to install the Azure Functions Core Tools. For YAML build definitions, it looks like this:
Once that step has run, the test will be able to execute as it does locally. Note however that at the moment, the Corvus library only supports Windows build agents – this won’t work if you’ve configured your pipeline to run a Linux agent.
GitHub actions is similarly straightforward. As with Azure DevOps, you’ll need to make sure your pipeline is configured to use a Windows agent using
runs-on: windows-latest in your pipeline YAML. Then simply add this step towards the start of your pipeline:
This approach should also work for other CI servers and their hosted build agents. If you’re using a private agent you have the option of installing the tools globally, meaning your build scripts can just assume they are present – this very much depends on how you prefer to manage build agents.
For SpecFlow users, the techniques I’ve shown in these posts will help ensure your integration tests are more complete by ensuring that functions under test are hosted in a way that closely matches the Azure environment they will ultimately run in.
I’ve tried to keep the posts simple by only covering testing HTTP triggered functions, but these techniques can equally be used to test functions that use other trigger types too. In our projects we’ve used it to test functions with blob, queue and Event Hubs endpoints, as well as functions using Durable extensions.
As mentioned above, the Corvus.SpecFlow.Extensions project is open source and contributions are accepted. If you encounter problems with it, please feel free to raise an Issue – and if you’re able, submit a pull request. And if you have any questions or feedback, just ask!