JSON, XPath, and Size Assertions

Response Assertion checks a response field against a pattern — powerful and flexible, but coarse. When you want to verify that a specific field inside a JSON or XML response has a specific value, you need an assertion that understands the structure of the response. JSON Assertion and XPath Assertion do exactly this: they navigate into the response body and verify individual fields by path.

JSON Assertion

JSON Assertion evaluates a JSONPath expression against the response body and optionally checks the extracted value.

Add it via right-click → Add → Assertions → JSON Assertion.

Configuration fields:

Example response:

{
  "user": {
    "id": 42,
    "name": "Alice",
    "role": "admin",
    "scores": [95, 87, 92]
  },
  "status": "active"
}

Assertion: verify user name is Alice

• JSON Path: $.user.name
• Additionally assert value: ✓
• Expected value: Alice

Assertion: verify ID is a number

• JSON Path: $.user.id
• Additionally assert value: ✓
• Match as regular expression: ✓
• Expected value: \d+

Assertion: verify role is not guest

• JSON Path: $.user.role
• Additionally assert value: ✓
• Expected value: guest
• Invert assertion: ✓

Assertion: verify scores array is not empty

• JSON Path: $.user.scores[0]
• Additionally assert value: ✗ (existence check only)

JSONPath syntax reference

JSONPath in JMeter uses the Jayway library, which follows the standard JSONPath spec closely. Test expressions interactively at jsonpath.com before adding them to JMeter.

XPath Assertion

XPath Assertion evaluates an XPath 1.0 or 2.0 expression against the response body. Use it for XML APIs, SOAP responses, and HTML pages.

Configuration fields:

Example XML response:

<response>
  <status>success</status>
  <user>
    <id>42</id>
    <name>Alice</name>
  </user>
</response>

Assertion: verify status is success

• XPath: //status[text()='success']

Assertion: verify user ID is 42

• XPath: //user/id[text()='42']

The XPath assertion passes if the expression matches one or more nodes. It fails if no nodes are found.

Stacking assertions

Multiple assertions on one sampler all run. The sample fails if any one fails. The Assertion Results listener shows which specific assertion caused the failure, making it easy to pinpoint the issue.

A robust pattern for a critical API endpoint:

POST /api/orders (HTTP Request Sampler)
├── Response Assertion — Response Code Equals 201
├── JSON Assertion — $.order.id exists
├── JSON Assertion — $.order.status = "pending"
├── JSON Assertion — $.order.total matches \d+(\.\d{2})?
└── Duration Assertion — under 2000ms

Each assertion is a separate element added as a child of the same sampler. They run in order from top to bottom. If the first one fails, JMeter still evaluates the others and marks all failures — you get a complete picture of what failed in one run.

JSON JMESPath Assertion

JMESPath is an alternative JSON query language to JSONPath, originally developed for AWS CLI. JMeter includes a JMESPath Assertion. The syntax is different from JSONPath:

Use JSONPath for most cases. Reach for JMESPath if you already use it in your application's AWS interactions and want consistent syntax across test assertions and application code.

Assertions on sub-requests

When an HTTP Request sampler triggers sub-requests (redirects, embedded resources), assertions by default apply to the main sample only. The Apply to field on the Response Assertion controls scope:

• Main sample only — default, applies to the primary request
• Main sample and sub-samples — applies to all responses including redirects and resources
• Sub-samples only — applies only to embedded resources
• JMeter variable — applies to a specific variable value

For API testing, Main sample only is almost always the right setting. For browser-simulation tests with embedded resources, choose Main sample and sub-samples to catch failures in static asset loading.

⚠️ Common mistakes

• Using Response Assertion Substring instead of JSON Assertion for structured data. Checking that "role":"admin" appears as a substring works until the response contains "previousRole":"admin" — then the assertion passes even when the user's current role is not admin. JSON Assertion $.user.role with value admin is precise.
• Forgetting that JSON Assertion by default only checks existence. Adding Assert JSON Path exists: $.user.name without checking "Additionally assert value" passes even if $.user.name is null or an empty string — the path exists. Enable the value check for meaningful verification.
• XPath Assertion on JSON responses. XPath Assertion expects XML. Applying it to a JSON response fails immediately with a parse error — not because the content is wrong, but because JSON is not XML. Use JSON Assertion for JSON responses, XPath Assertion for XML/SOAP.

🎯 Practice task

Add content-aware assertions to verify specific response fields.

1. Run a request that returns a JSON response (you can use https://httpbin.org/get which returns a JSON object including your request details). Add a JSON Assertion:

   • JSON Path: $.headers.Host
   • Additionally assert value: ✓
   • Expected value: httpbin.org

2. Add a second JSON Assertion to the same sampler:

   • JSON Path: $.url
   • Additionally assert value: ✓
   • Match as regular expression: ✓
   • Expected value: https://httpbin.org/.*

3. Run with both assertions enabled — both should pass. Then change one expected value to something deliberately wrong and confirm only that assertion's failure appears in the Assertion Results listener.

4. Target https://httpbin.org/xml which returns XML. Add an XPath Assertion:

   • XPath: //slideshow/@title
   • Validate XML: ✓

5. Stack a Duration Assertion (5000ms) and a Size Assertion (> 100 bytes) on the same XML sampler. Run and confirm all three assertions pass. The sample should be green with three passing assertions visible in Assertion Results.