Best practices for validating API responses

To ensure that your API response validations yield meaningful results, it’s important to create targeted checks that align with the goal of the test. This article offers several best practices to help you get the most out of API test assertions:

• Be mindful of status codes
• Break down complex assertions
• Leverage partial match
• Include negative testing
• Use low-code assertions whenever possible

Be mindful of status codes

When you run a new step in the API Test Editor, mabl adds a default assertion that the status code is 200. If you are validating an API that returns a different status code, such as 201 or 204, update the assertion to ensure the step passes.

Break down complex assertions

Avoid combining multiple validations into a single assertion. Instead, create several smaller assertions that focus on each area that you want to validate. This approach makes your test more resilient and easier to troubleshoot when the test fails.

Suppose you need to validate that an API returns a list of contacts in the state of California, including name, address, and phone number. If you assert against the entire response body, the test could fail because of a minor change even though the API is still functioning as expected. To avoid this issue, create several smaller assertions to validate the fields that are critical to the API’s functionality. For example:

• Check that the API returns the correct number of results
• Confirm the name of the first result
• Confirm that the address of the second result contains CA.
• Confirm that the phone number of the third result matches the regex pattern \(\d{3}\) \d{3}-\d{4}

Leverage partial match

mabl offers options for asserting against partial matches, including starts with, ends with, contains, and matches regular expression. Partial match options can help you focus on what matters most without breaking the test if the response evolves. Examples of partial match assertions include:

• Assert that the Content-Type header starts with image/
• Verify that the filename ends with .jpg
• Confirm that the format of the date field matches the regex pattern 20\d{2}-\d{2}-\d{2}

Include negative testing

To ensure your API handles errors correctly, include negative testing for failure conditions. For example, create a step that sends an unauthenticated request and assert that the status code of the response is 401.

Common error status codes that you can test include:

• 400 - bad request
• 401 - unauthorized
• 403 - forbidden
• 404 - not found

Use low-code assertions whenever possible

In mabl, you have the flexibility of validating API responses with low-code assertions and custom script validations. Whenever possible, use low-code assertions. They are easier to maintain, and their results are easily viewable from the mabl app.

Reserve the use of custom script validations for the following circumstances:

• Validating an XML response body
• Validating a complex scenario that cannot be verified using low-code assertions, such as verifying that the checksum of a field matches the expected value