Automation Integration Test with Mock response service

When the API is associated with a third party. It is difficult to integrate a test directly to a service, especially one from a different company. As a result, using a mock service to prepare response data is a good idea.

The integration test is located in the center of the Pyramid. This section would be tested in the service layer; it is a function test as it provides a service that connects to a network, a database, or another services.

When we started the WebAPI, we were ready to call the API endpoint, as shown in the diagram. Because we do not need to send data to a third-party service, we must mock the service response (It has many factors, such as not want to real sending and distributing another service if the third party is outside of the company or another project, because when we need to test frequency and the project starts up in memory etc.)

Many developers wonder how to differentiate between unit tests. In the context of unit testing, we test only the method and do not need to check data access or table storage if we use the cloud. That is why we need automation integration testing.

As a result, integration testing ensures that endpoints can create, update, or retrieve data as expected, demonstrating that the system is operationally sound. and do not focus on responses from third parties because they are outside the scope of the automation testing project. The second meaning of the project is that we can test the API whenever we need to.

So, before you create data to mock, you should check the service of your repository call.

My project began with Microsoft.AspNetCore IWebHostBuilder are used to provide mock data. Same as the exemple below.

And what I expected was a HttpResponseMessage and data access or data insert in Azure storage, indicating that your API is operational.

I hope my blog more or less help you to implement automation integration test. Thank you!!