- Is Your Serverless Application Testable? – Azure Functions
- Is Your Serverless Application Testable? – Azure Logic Apps
I’ve talked about testable Azure Functions in my previous post. In this post, I’m going to introduce building a testable Azure Logic Apps.
Sample codes used in this post can be found here.
- As a DevOps engineer,
- I want to search ARM templates using Azure Logic Apps
- So that I can browse the search result.
Workflow in Logic Apps
Based on the user story above, the basic workflow in Logic Apps might look like:
- An HTTP request triggers the workflow by hitting the
- The first action,
HTTPin this picture, calls the Azure Function written in the previous post.
- If this action returns a response with an HTTP status code greater or equal to 400, the workflow takes the path at the left-hand side, executes the
ErrorResponseaction and terminates.
- If this action returns a response with an HTTP status code less than 400, the workflow takes the path at the right-hand side and executes the
Parse JSONaction followed by the
- If the condition returns
true, the workflow runs the
OkResponseaction; otherwise it runs the
NotFoundResponseaction, and terminates.
Therefore, we can identify that the
HTTP action returns three possible scenarios – Error, Success with no result and Success with result. Let’s keep this in mind.
In fact, the workflow is a visual representation of this JSON object.
As a Logic App is basically a JSON object, we can easily plug it into an ARM template and deploy it to Azure so that we use the Logic App workflow straight away.
THERE IS NO CODE AT ALL.
From the unit-testing point of view, no code means we’re not able to test codes. Logic Apps only works in Azure cloud environment, ie. we can’t run test in our isolated local development environment. Well, being unable to run unit-test Logic Apps doesn’t necessarily mean we can’t test it at all.
Let’s see the picture again.
There’s a point where we can run test. Yes, it’s the
HTTP action – the API call. As we’ve identified above, there are three scenarios we need to test. Let’s move on.
Manual Testing the Logic App
First of all, send a normal request that returns the result through Postman.
This time, we send a different request that returns no data so that it returns 404 response code.
Finally, we send another request that returns an error response code.
Tests complete! Did you find any issue in this test process? We actually hit the working API defined in the
HTTP action. What if the actual API call causes any side effect? Can we test the workflow WITHOUT hitting the actual API? We should find a way to decouple the API call from the workflow to satisfy testabilities. API mocking can achieve this goal.
I wrote a post, API Mocking for Developers. In the post, I introduced how to mock APIs using Azure API Management. This is one way of mocking APIs. Even though it’s very easy to use with a Swagger definition, it has a costing issue. Azure API Management is fairly expensive for mocking. What if we use Azure Functions for mocking? It’s virtually free unless more than one million times of function calls per month occur.
Therefore, based on the three scenarios identified above, we can easily write Functions codes that returns dummy response like below:
It seems to be cumbersome because we need to write code for mocking APIs. So, it’s totally up to you to use either Azure API Management or Azure Functions for mocking.
Now, we’ve got mocked API endpoints for testing. What’s next?
Logic Apps for Testing – Manual Test
As we identified three scenarios, we need to clone the working Logic Apps three times and replace the API endpoint with the mocked ones. Here are the three Logic Apps cloned from the working one.
Each Logic App needs to be called through Postman to check the expected result. In order to pass the test, the first one should return error response, the second one should return 404 and the last one should return 200. Here’s the high level diagram of testing Logic Apps based on the expected scenarios.
We’re now able to test Logic Apps with mocked APIs. However, it’s not enough. We need to automate this test to integrate a CI pipeline. What can we do further?
Logic Apps for Testing – Automated Test
If we write a PowerShell script or script to call those three testing Logic Apps, we can call the script within the CI pipeline.
Here’s the high level diagram for test automation.
During the build process, Jenkins, VSTS or other build automation server calls the PowerShell script. The script runs three API requests and checks their responses. If all requests return expected responses respectively, we consider the test succeeded. If any of request returns a response different from expectation, the test is considered as failure.
So far, we’ve briefly walked through how to run tests against Logic Apps by API mocking. By decoupling API request/response from the Logic App, we can focus on the workflow itself. I hope this approach helps writing your Logic Apps workflow.