Mocking Server Response Data with Postman on Android

As a mobile developer, we have to handle every response from the server to make sure our beautiful applications work properly.

Once you have your mock server you can focus on UI regression testing.

1. Create a new mock server by clicking on New at the left top and choose Mock Server

2. Add the /repositories path and Response Body “Mock body sample”

4. Create the mock server. You will see your mock URL like this.

5. Expand the “Github Mock Server” collection to see your API request and don’t forget to change your environment to “Github Mock Server” at the top right and try to call your mock server by clicking send. Boom!!!!

Congratulations! you have your own Mock server!!!

[
  {
    "id": 1,
    "name": "Android-Test1",
    "description": "Android-Test1 description"
  },
  {
    "id": 2,
    "name": "Android-Test2",
    "description": "Android-Test2 description"
  },
  {
    "id": 3,
    "name": "Android-Test3",
    "description": "Android-Test3 description"
  },
  {
    "id": 4,
    "name": "Android-Test4",
    "description": "Android-Test4 description"
  }
]

1. You can update the default response by clicking on Examples and choosing Default.

Yes! You are done with your mock server!

Now, let’s try our mock server on our Android Project.

android.buildTypes {
    mock {
        buildConfigField "String", "BASE_API_URL", "\"https://c77b2784-b60b-491b-af7e-273c356ef4a2.mock.pstmn.io\""
    }
    debug {
        buildConfigField "String", "BASE_API_URL", "\"https://api.github.com/\""
    }
    release {
        buildConfigField "String", "BASE_API_URL", "\"https://api.github.com/\""
    }
}

apply from '../common-properties.gradle'
...
android {
...

4. Now you can access your base API URL everywhere in your app.

BuildConfig.BASE_API_URL

Why Mock Server Responses in Android Development?

• Speeds Up Development: Developers can work on the app's functionality without waiting for the backend API to be complete or stable.
• Facilitates Testing Edge Cases: Mock data allows you to simulate a wide range of server responses, including success, errors, and edge cases like timeouts or large payloads.
• Offline Development: Enables you to continue development even without an active server or internet connection.
• Reduces Dependencies: Minimizes reliance on backend teams, allowing frontend and backend workstreams to progress in parallel.

Advanced Features of Postman Mock Server

• Postman allows you to define dynamic responses using mock server variables. These variables can simulate different conditions such as user-specific data or API versions.
• Example: Use {{$randomInt}} to return a random number in the response, simulating dynamic data from the server.

• Mock server allows you to configure response delays. This is useful for testing how your app handles slow network connections.
• Example: Add a delay of 500ms to simulate a slow server response.

• Postman allows you to manage multiple versions of mock responses. This is especially useful if your API evolves over time, enabling you to test your app against different API versions without modifying the backend.

Integrating Postman Mock Server into Android Development Workflow

• Use Postman to simulate network failures, such as a 500 Internal Server Error or 404 Not Found. This ensures your app can handle these scenarios gracefully and maintain a good user experience.

• Mock paginated data to test how your app handles lists or feeds. For example, create multiple responses for page=1, page=2, etc., to simulate loading additional data.

• Postman mock servers can be configured for different environments (e.g., staging, production). Use environment variables in Postman to test how your app behaves with different configurations.

Common Challenges and Solutions

• Problem: Switching between mock server and production API endpoints manually can lead to errors.
• Solution: Use build variants or configuration files in your Android project to toggle between mock server URLs and production URLs.
  
  

• Problem: Mock servers typically return static responses, which may not cover all real-world scenarios.
• Solution: Use Postman’s scripting features to add logic for dynamic responses, such as generating random data or returning responses based on request parameters.
  
  

• Problem: Testing authenticated API calls with mock servers can be tricky if the app requires tokens.
• Solution: Mock the authentication endpoint to return a static token, which can then be used in subsequent requests to the mock server.
  
  

Debugging Tips for Postman Mock Server

1. Inspect Mock Server Logs:
   • Postman provides detailed logs of mock server activity. Use these logs to debug requests and responses during testing.
     
     
2. Validate JSON Schema:
   • Use Postman’s built-in JSON schema validation feature to ensure that your mock responses conform to the expected API contract.
     
     
3. Test Error Scenarios Thoroughly:
   • Simulate edge cases, such as invalid inputs, missing parameters, or large payloads, to identify potential issues in your app’s error handling logic.
     
     

Best Practices for Mocking with Postman

1. Document Your Mock Scenarios:
   • Maintain clear documentation of all mock scenarios, including request and response examples. This ensures that the entire team can understand and use the mock server effectively.
     
     
2. Use Consistent Naming Conventions:
   • Name your mock collections and responses in a way that reflects their purpose (e.g., User Login - Success, User Login - Invalid Credentials).
     
     
3. Integrate Mock Testing into CI/CD:
   • Use Postman’s Newman CLI to run tests against the mock server as part of your continuous integration pipeline, ensuring consistent behavior across builds.
     
     

Conclusions

1. With the mock server, you can mock any response and any code status that you want to test easily, and it improves your test quality.
2. You don’t have to make mock data inside the front-end projects, you can use the mock server and re-use it anywhere.
3. You have a single source of information.
4. Easy to communicate between Back-end and Front-end with an excellent tool from Postman to make API documents.
5. Testers can cover all of the expected test cases.
6. Most importantly, this can speed up the development because you don’t have to wait for the Back-end team to mock the data for testing anymore.
   
   

• https://learning.postman.com/docs/postman/mock-servers/setting-up-mock/
• POST/CON 2018 workshop in review: Mock servers