Diving into integration testing
Integration testing is obviously an essential step when you want to develop stable software. Most of the time you want dive a bit deeper into the testing process and go beyond the happy flow tests and one way to go this is test with API mocking. However, when you cover a wide variety of tests, you will also get a wide variety of responses from your mocked endpoints. I will explain this a bit more as we go along.
In this demo we will run our tests from our favourite testing framework.
- During setup we will configure our responses in a storage account we expect during our tests.
- While running the test we will call our API which is subject under test(=SUT)
- The SUT will forward the request to the mocked endpoint in API-M
- API-M will fetch the expected response to return and return it to the SUT.
- The test scenario is verified if the request was the request we expected
For uploading and downloading a blob I recommend you to take a look at the Client Library options in Azure Documentation
Import API Mocking
Next, we need to import the API we want to mock. You can do this via the various methods. The most easy one, based on an Open-API spec is described in the Azure Docs here
It doesn’t matter if the URL points towards the real API. That is something we will modify in the next step.
Depending on the storage account container we use to set up the public access role, we do not need to authenticate. Instead we can go directly to the URL.
So the easy way to configure this is to go to the API in Azure API Management and set the backend service URL to the storage container you want to fetch the results from, and to rewrite the URL to the blob file you uploaded – or will upload – for that operation.
A sample inbound section for the policy will look like this:
Unfortunately, request verification is not as easy as response mocking. When a request comes in, we will upload the file to Azure Storage inside our Azure API-M Operation policy, but for create/update operations it is required to authenticate this in Azure Storage. We do not need to enter a ClientID and ClientSecret as it is done via Managed Identity, but nevertheless the policy will be a little bit more complex.
Here is an example inbound section for a policy to upload the request:
Subscribe to our RSS feed