Assertions

Assertions validate that your API response meets expected criteria. A test passes only when all assertions pass.

Overview

Each test can have multiple assertions. Assertions are evaluated in order, and you can configure whether to stop on the first failure or continue checking all assertions.

Assertion Types

Status Code

Validate the HTTP response status code.

Pattern	Matches
200	Exactly 200
2xx	Any 200-299
200,201	200 or 201
2xx,3xx	Any 200-399

Examples:

• 2xx - Any successful response
• 200,201,204 - Common success codes
• 200 - Exactly 200 OK

Response Time

Ensure the response completes within a threshold.

• Threshold: Maximum time in milliseconds

Example: 500 fails if response takes longer than 500ms.

Use this to catch performance degradation before it impacts users.

JSON Path

Extract a value from JSON responses and compare it.

• Path: JSONPath expression (e.g., $.status, $.data[0].id)
• Expected: The value to match

Examples:

Path	JSON	Result
$.status	{"status": "ok"}	ok
$.count	{"count": 5}	5
$.items[0].name	{"items":[{"name":"first"}]}	first
$.data.enabled	{"data":{"enabled":true}}	true

Contains

Check if the response body contains a specific string.

• Text: The string to search for

Example: "healthy" passes if the response contains the word "healthy" anywhere.

This is case-sensitive. Use for simple text matching when JSONPath isn't needed.

Regex Pattern

Match the response body against a regular expression.

• Pattern: A valid regex pattern

Examples:

Pattern	Matches
"status":\s*"ok"	"status": "ok" or "status":"ok"
version.*[0-9]+\.[0-9]+	version: 1.0, version 2.3
(?i)success	Success, SUCCESS, success

Header Exists

Verify a specific header is present in the response.

• Header Name: The header to check (case-insensitive)

Examples:

• Content-Type - Verify content type is set
• X-Request-Id - Verify request tracking header
• Cache-Control - Verify caching headers

Header Value

Verify a header has a specific value.

• Header Name: The header to check
• Expected Value: The expected value

Stop on Failure

When enabled, the test stops evaluating remaining assertions after a failure. This is useful when:

• Later assertions depend on earlier ones
• You want to avoid unnecessary processing
• The first failure is the most important

When disabled, all assertions are evaluated and all failures are reported.

Best Practices

Order Matters

Put the most important assertions first:

1. Status code (is the request successful?)
2. Response time (is it fast enough?)
3. Content validation (is the data correct?)

Start Simple

Begin with basic assertions:

Status Code: 2xx

Add more specific assertions as needed:

Status Code: 200
Response Time: < 500ms
JSON Path: $.status = "healthy"

Avoid Over-Asserting

Don't assert on volatile data:

• Timestamps
• Random IDs
• Counts that change frequently

Focus on stable indicators of health.