skip to content

In JMeter's JSON Assertion, how is the Expected Value compared against the extracted value by default?

level: middleimportance: nice to knowfreq 33%

answer

  1. The comparison is opt-in first
  2. One checkbox enables the value fields
  3. Its neighbour is already ticked
  4. Patterns must match in full
  5. The JMESPath sibling behaves identically

basics

~20 s

As a regular expression that must match the extracted value in full. Match as regular expression is ticked by default on a newly added JSON Assertion, and the same is true of the JSON JMESPath Assertion.

solid answer

~40 s

The value comparison is opt-in and regex-first. Nothing is compared until **Additionally assert value** is ticked; that checkbox enables the *Expected Value* field and the **Match as regular expression** checkbox beside it. On a newly added element `Match as regular expression` is already **ticked**, so the expected value is compiled as a regular expression and has to match the extracted value's string form **in full**, not merely appear inside it. Untick it and the expected value is instead parsed as JSON and compared for equality. The JSON JMESPath Assertion behaves the same way and defaults the same way. This catches people out because an expected value that looks like plain text — `12.50`, `ACC-1001`, `a+b` — is quietly a pattern, and characters such as `.`, `+` and `[` stop meaning themselves.

go deeper

for a junior

Know that a JSON Assertion checks that a path exists, and that comparing a value is a separate checkbox you have to tick before the Expected Value field does anything at all.

for a middle

Explain the default: the expected value is a regular expression matched in full against the extracted value's string form, and unticking the box switches to a JSON parse and an equality comparison.

for a senior

Spot the failure modes in a real plan: an expected value containing a dot or a plus behaving as a pattern, a partial match that never satisfies a full match, and an indefinite path used without an asserted value.

for a principal

Decide whether plans in your organisation may rely on this default at all, given that the checkbox state is invisible at a glance and changes the meaning of every expected value in the plan.

## Five controls, in the order they take effect The JSON Assertion panel is small but its fields gate each other: 1. **Assert JSON Path exists** — the only mandatory field. On its own, the element parses the body, fails if it is not JSON, and fails if the path resolves to nothing. 2. **Additionally assert value** — off by default. Until it is ticked, *Expected Value* and *Match as regular expression* are disabled and the element is a pure existence check. 3. **Match as regular expression** — **ticked by default** on a new element, and enabled only while step 2 is ticked and *Expect null* is not. 4. **Expect null** — compares against a JSON null instead of a value, and disables the two fields above. 5. **Invert assertion** — flips the whole verdict at the end. ## What the default comparison actually does With the regex box left at its default, the expected value is compiled as a regular expression and matched against the string form of whatever the path extracted, using a **full match**. Two things follow, and both surprise people: - **Metacharacters bite.** `12.50` matches `12X50` because `.` is any character. `a+b` is a pattern with a repetition operator, not the literal text. `ACC-1001` happens to be safe; `ACC[1001]` is not. - **A partial match is not enough.** The expression has to account for the extracted value end to end, so `ok` does not match `status ok`. Untick the box and the semantics change completely: the expected value is parsed as JSON and compared for equality with the extracted value. That is the right setting when you know the exact value and it contains punctuation. ## When the path returns an array If the JSON Path resolves to an array, the element iterates it and the assertion succeeds when **any** element satisfies the comparison. To assert an empty array, set the expected value to the literal string `[]`. One related trap has a version boundary worth naming. With an **indefinite** JSON Path — one that can match many nodes, such as `$.items[*].id` — and *Additionally assert value* left off, an empty extraction used to pass, which made such assertions silently useless. **Since JMeter 5.5** the element fails in that case instead. The manual's advice remains to assert a value whenever the path is indefinite. ## The same rules in the JMESPath sibling The **JSON JMESPath Assertion** exposes the same five controls and the same regex default, under a first field labelled *Assert JMESPath exists*. Two differences are worth carrying: | | JSON Assertion | JSON JMESPath Assertion | |---|---|---| | Expression syntax | JsonPath | JMESPath | | Empty expression | rejected as a missing path | never compiles, so the element errors | | Missing path | reported as a failure | the expression yields null, reported as a failure | Neither element offers an *Apply to* scope selector, and neither reads anything but the response body — no headers, no response code, no URL. When the check needs one of those fields, it is a Response Assertion's job. ## The worked case The checkout body must carry an `orderId`, and someone wants to tighten that from "present" to "looks like an id": - **Assert JSON Path exists**: `$.orderId` - **Additionally assert value**: ticked - **Expected Value**: `[0-9a-f]{8}-[0-9a-f]{4}-.*` With the regex default left alone that is exactly right, and it reads as a pattern because it is one. The failure comes when the next person copies the element, changes the expected value to the literal id `4f2c-11`, and does not notice that the hyphen is fine but the value is now still being treated as a pattern that must match the whole string. It happens to work here; it stops working the moment a `.` or a `+` appears in a real id. ## What to check first when a JSON Assertion behaves oddly - Is *Additionally assert value* even ticked? If not, the expected value in the field is decoration and only existence is being tested. - Is the comparison regex or literal? The checkbox state is invisible in a screenshot of a collapsed panel. - Is the path definite? An indefinite path with no asserted value is a configuration the element now rejects rather than passes. - Is the body actually JSON? A parse failure is reported as the assertion's failure message, which is the fastest signal that the endpoint returned something else entirely.

  • You expect the exact value 12.50. What do you configure, and why is the default wrong here?
    Untick **Match as regular expression** so the expected value is parsed as JSON and compared for equality. Left at the default, `12.50` is a pattern in which the dot matches any character, so a body carrying `12X50` would satisfy the assertion.
  • What does a JSON Assertion do when the path resolves to an array rather than a single value?
    It iterates the array and the assertion succeeds if any element satisfies the comparison. To assert that the array is empty, put the literal string `[]` in the expected value. With an indefinite path and no asserted value, an empty extraction is a failure rather than a pass.

saying these in an interview costs you the question

  • Assuming Expected Value is compared as plain text
  • Expecting a partial match to satisfy the comparison
  • Filling Expected Value without ticking Additionally assert value
  • Pointing a JSON Assertion at response headers
  • Believing an indefinite path with no value still passes