skip to content

In JMeter, how do you fail a sampler whose 200 response body omits the orderId field?

level: middleimportance: must knowfreq 70%

answer

  1. Status alone decides the sampler's verdict
  2. The check is a separate element
  3. Body text, or a parsed path
  4. Three elements can express it
  5. Verdict is combined with existing status

basics

~10 s

Attach an assertion under the sampler. A Response Assertion on Text Response with a Substring or Contains pattern, or a JSON Assertion asserting that the path $.orderId exists, turns the green sample red.

solid answer

~50 s

JMeter marks an HTTP sample successful from its status alone, so a body check has to come from an assertion element attached under the sampler. Three elements can express it. A **Response Assertion** with *Field to Test* set to `Text Response` and a `Substring` pattern of `"orderId"` is the simplest. A **JSON Assertion** with *Assert JSON Path exists* set to `$.orderId` is stricter: it parses the body first, fails if it is not JSON, and fails again if the path resolves to nothing. A **JSR223 Assertion** can do it in Groovy by inspecting the bound `SampleResult` and calling `AssertionResult.setFailure(true)`. Whichever you use, JMeter combines the assertion's verdict with the status the sample already carries, so a failing assertion is what makes the sample red. *Why* a success status does not by itself mean success is a testing principle owned elsewhere; this is only the element that performs the check.

code

json · 4 lines
json
{
  "status": "ok",
  "message": "order accepted"
}

go deeper

for a junior

Know that a green sample only means the status was acceptable, and that checking the body needs a separate assertion element added under the sampler. Naming the Response Assertion is enough at this level.

for a middle

Explain the configuration: Field to Test set to Text Response with a Substring pattern, or a JSON Assertion whose Assert JSON Path exists field names the path, and how the assertion's verdict is combined with the sample's status.

for a senior

Show judgment about which element states the rule most exactly and which gives a failure message an on-call reader can act on, and mention the parse-first behaviour that catches an HTML page served with a 200.

for a principal

Set the convention for what content checks a plan is allowed to carry and in which element they are written, so that the checks stay readable in the .jmx and consistent across the teams that maintain the plans.

## The problem the element has to solve An HTTP Request sampler decides its own status from the response code: `4xx` and `5xx` are unsuccessful, everything else is a pass. A checkout endpoint that answers `200 OK` with `{"status":"ok","message":"order accepted"}` and no `orderId` therefore produces a **green sample**. Nothing in JMeter's sampler layer looks inside the body. The check has to be added as an assertion element in the sampler's subtree. ## Option one: a Response Assertion on Text Response The declarative choice, and the one most plans use: - **Field to Test** — `Text Response`, the response body with the HTTP headers excluded. - **Pattern Matching Rules** — `Substring` for a literal fragment, or `Contains` when the value's shape matters. - **Patterns to Test** — `"orderId"` under `Substring`, or `"orderId"\s*:\s*"[0-9a-f-]+"` under `Contains`. Do not reach for `Matches` here. `Matches` requires the expression to account for the whole body, so a fragment pattern fails on every sample and the plan looks broken rather than strict. The Response Assertion is also the only one of the three that carries a **Custom failure message** field, so the failure text in the results can name the business rule instead of quoting the pattern back at you. ## Option two: a JSON Assertion on the path A JSON Assertion is stricter in three separate ways, and each one is a check the Response Assertion is not making: 1. It parses the body and **fails if the data is not JSON at all** — an HTML error page served with a `200` is caught here and would slip past a `Substring` check only if that page happened not to contain the text. 2. It fails when the path **is not found**, which is exactly the missing-field case. 3. With *Additionally assert value* ticked, it also compares the value that the path resolved to. Set **Assert JSON Path exists** to `$.orderId` and leave the value assertion off, and you have expressed "the body must carry this field" precisely. One caveat is worth knowing: with an *indefinite* path such as `$.items[*].id` and no assertion value set, JMeter fails the assertion when the extraction comes back empty — behaviour introduced in JMeter 5.5 to stop such assertions always passing. The sister element **JSON JMESPath Assertion** does the same job with JMESPath syntax instead of JsonPath; its expression may never be empty, because an unset expression does not compile. ## Option three: a JSR223 Assertion When the rule is conditional — the field is required only for a particular order type, say — a **JSR223 Assertion** running Groovy is the escape hatch. It receives the sample as the bound object `SampleResult` (also reachable as `prev`) and the verdict object as `AssertionResult`. The script does not return its verdict; it **sets** it, by calling `AssertionResult.setFailure(true)` and `AssertionResult.setFailureMessage(...)`. A script that merely evaluates to `false` asserts nothing at all. ## How the verdict reaches the sample After each assertion runs, JMeter combines its outcome with the status the sample is already carrying: the sample stays successful only if it was successful **and** the assertion neither failed nor errored. Two consequences follow: - A failing assertion always reddens a green sample. - A passing assertion never greens a red one. The `Ignore Status` checkbox on a Response Assertion is the deliberate exception, and it works by resetting the sample's status before the patterns are evaluated. ## Choosing between the three | Element | Reads | Fails when | Needs code | |---|---|---|---| | Response Assertion | any of eight request/response fields | the pattern rule is not satisfied | no | | JSON Assertion | the response body only | the body is not JSON, or the path is missing | no | | JSR223 Assertion | anything on the SampleResult | the script sets failure on AssertionResult | yes | For a body that must carry a field, a JSON Assertion states the intent most exactly and gives the most useful failure message; a Response Assertion is the lighter, fully declarative alternative that anyone reading the plan will recognise. Reach for JSR223 only when the condition genuinely cannot be written as a path or a pattern.

  • The endpoint sometimes returns an HTML error page with a 200 status. Which of the two declarative options catches that?
    The JSON Assertion. It parses the body before doing anything else and fails when the data is not JSON, so an HTML page is caught on the parse. A Response Assertion with a `Substring` pattern only catches it indirectly, by the pattern happening not to appear in the HTML.
  • What does a Response Assertion report when the response body is completely empty?
    It fails with the message `Response was null`. An empty field is treated as a failure rather than as a pattern that did not match — except when `Not` is ticked, in which case an empty field is treated as a pass, since nothing can be found in it.

saying these in an interview costs you the question

  • Claiming the HTTP sampler itself checks the body
  • Using Matches with a small fragment pattern
  • Expecting a JSR223 script's return value to be the verdict
  • Thinking a passing assertion can rescue a failed sample
  • Pointing a JSON Assertion at response headers