Create a Mock Service for Testing a Web Application

This tutorial shows an end-to-end scenario for testing a digital banking application, using Mock Services to simulate a third-party service.

The example application for this tutorial is called Digital Bank, and it represents a simple web interface for online banking, built as a basic Java app.

The Digital Bank application, like any other application, uses third party components wherever possible. One such third party service enables the functionality that lets users search for a banking location based on zip code. The service is a third-party API that the application connects to based on the API URL, which is defined in the application's properties file.

Testing is a continuous exercise, and interruptions in third-party services or costs associated with testing against the API should not be blockers.

This scenario assumes a situation where the API service unexpectedly becomes unavailable. Were this a common occurrence, perhaps a Mock Service would already be available as a Template. But this situation is not common, and with a release looming, testing against the API is an operation that can't wait. Now, let's see how BlazeMeter helps you mitigate this situation in minutes to complete critical testing without being affected by constraints.

Follow these steps:

1. Locate a source of Transaction data for the live service.
   For this tutorial, assume that you have a HAR file with a couple of example ATM searches. Here is a snippet from the file:
   

   "pages": [
         {
           "startedDateTime": "2019-07-10T13:15:13.284Z",
           "id": "page_3",
           "title": "https://uat-api.synapsefi.com/v3.1/nodes/atms?zip=94203",
           "pageTimings": {
             "onContentLoad": 1472.3379999923054,
             "onLoad": 1590.7770000048913
   

   Note: If you did not have a file available, you could access the Swagger specification for the API and download it as a JSON file.
2. Open BlazeMeter, click the Service Virtualization tab, and select Asset Catalog.
   
   
3. Drag the HAR file onto the upload box.
   The Import Transactions dialog opens.
   
4. Type 'ATM Search', and click Add Service.
5. Add a tag named ATM, and press Enter.
   You can add tags now to automatically tag all Transactions that you import. Tags can help you find Transactions within a large service. As you add more Transactions to the ATM Search service over time, you can give the Transactions more specialized tags.
   
6. Click Import.
   The Transactions in the HAR file are imported into the repository.
7. Filter the Transactions view by the newly created ATM Search service.
   
   You can now see the two transactions imported from the HAR file into the ATM Search service.
8. Expand the first transaction.
   
   For reuse and sharing, it's important that you give all entities unique names.
9. Give the transaction a meaningful name and description:
   
   Add a 'positive' tag to denote that the URL should return a positive result.
10. Examine the URL in the Request Matcher field.
    
    This Transaction sends a simple GET request to the API. The Query Parameters section shows that this Transaction searches specifically for 94203, and the response data shows that two ATM locations match the query.
    
    You are happy with this Transaction and will use it for your ATM search acceptance test.

    Note: In the future, you would likely want to go back and cover other scenarios for the service, such as an invalid zip code, a partial match zip code, and more. For now, because the goal is to quickly verify that the API is working, you move forward with a single Transaction. You can add more Transactions to the Service over time.

11. Click the Mock Services section and click the Add button next to Mock Services.
12. Give the Mock Service a meaningful name and description, select the ATM Search Service, and move the single Transaction in the service to the right pane:
    
13. Click Save.
14. Click Run Mock Service.
    When the Mock Service status is Running, that means that BlazeMeter has created an endpoint containing the Transactions previously defined in your Mock Service for you to run your tests against.
15. Click the icon next to the Endpoint field to copy the endpoint of the Mock Service to your clipboard.
    To test against the Mock Service, you have to redirect the Digital Bank application to call the Mock Service instead of the real one. This step is required for any application, but will differ based on the application architecture and which service you are redirecting. The Digital Bank stores the ATM Search connection information in a properties file.
16. Open the application.properties file for the Digital Bank, find the io.demo.bank.atm.host section, add a new line with the Mock Service endpoint, uncomment the new line and comment out the line with the live service URL, and save the file.
    
17. Restart the Digital Bank application.
    The Digital Bank is now running against the Mock Service. At this point, any testing of the ATM search functionality will return results based on the Transactions in the Mock Service. A search for 94203 returns the two results stored in the Transaction. Other searches may not return meaningful results, because the Mock Service only has a single Transaction.

This tutorial showed how you can quickly provision a Mock Service to remove testing constraints and help your testing keep up with the speed of your application delivery pipeline.