Conditional Logic & Error Handling

Building robust tests means accounting for more than just the “happy path.” Your tests should be intelligent enough to handle different API responses and explicitly validate that your API fails correctly.

Branching with the IF Node

The IF Node is the primary tool for creating adaptive test flows. It allows you to execute different steps based on a condition, which is typically a value from a previous API response.

Example: Check if a resource needs to be created

1. API Node: Get Resource

   • GET /my-resource/{{resourceId}}
   • This call might return a 200 OK if the resource exists, or a 444 Not Found if it doesn’t.

2. IF Node:

   • Condition (JSONata): response.status === 404

3. “Then” Branch (Child of IF Node):

   • API Node: Create Resource
     • POST /my-resource
     • This branch only runs if the GET request failed with a 404, ensuring the resource is created before the rest of the test proceeds.

Validating Error Responses

A critical part of API testing is verifying that your API handles errors correctly and returns the proper status codes and error messages.

Don’t let your test fail just because you received a 4xx or 5xx status code. Instead, treat it as a successful test run if the error is expected.

Example: Test for a “Not Found” error

1. API Node: Get a non-existent user

   • GET /users/a-user-that-does-not-exist

2. Assertions on the API Node:

   • response.status === 404
   • response.body.error === "User not found"

This test case will pass only if the API correctly returns a 404 status with the specified error message.

Using breakCondition in Loops

When polling or iterating, you often need to stop the loop once a certain condition is met. The breakCondition property, available on Loop and Iteration nodes, is perfect for this.

It uses a JSONata expression that is evaluated after each iteration. If the expression returns true, the loop terminates immediately. This is a key component of the Polling Pattern.