Published on 10/23/2021, Updated on 08/16/2024
Reproducibility of the defect is important to:
It is also important that the defect is reproducible in non-production environments, such as QA and Development.
Inability to reproduce the problem consistently in the same environment OR
Not having identical data (that exposes the defect in the application) in the lower environments makes it difficult to develop and deploy the defect fix.
Before the development team can begin working on a fix, data must be created, copied or migrated into the lower environments. However, copying the data into another environment isn’t always straight forward because of the dependencies and relationships between objects that make up the data being copied.
If the data that exposes the defect in the application is obtained by calling a Web/HTTP/REST API then knowing the contents of the API response might be sufficient to reproduce the problem.
Even if the API response body contents are fully known, how is that sufficient to reproduce the problem in the same or lower environments?
We can utilize a API mock server to create a mock API endpoint that is identical to the real API endpoint. The application affected by the defect can call the mock API to receive the exact data that exposes the flaw, because mock APIs can be instructed to return specific responses when invoked. Having a mock API can help reproduce the problem in the lower environments and the developers can begin working on the fix instead of waiting for the data team to finish migrating the needed data into the lower environments. Depending on the application architecture, mock APIs can speed-up the the time it takes to fix a bug by eliminating the need to reset or recreate the test data repeatedly because mock APIs can return the needed data to the calling application consistently.
If you would like to talk about a specific scenario and if ApiOnCloud's mock API server can help with your particular use-case then contact us at info@apioncloud.com