Test a response

A request can carry tests: assertions evaluated against its own response on every send. The same assertion shape is used by a chain’s assert node, and one evaluator in the engine serves both.

Write one

The Form view’s Tests tab edits them. In YAML:

- name: Create user
  method: POST
  url: "{{baseUrl}}/users"
  body:
    contentType: application/json
    content: '{"email":"a@example.com"}'
  tests:
    - source: status
      op: eq
      expected: "201"
    - source: body
      path: id
      op: exists
    - source: header
      path: content-type
      op: contains
      expected: application/json

The vocabulary

An assertion is a source, an optional path, an op, and an optional expected.

Sources

source	What path means
status	— (unused)
body	A dotted JSON path, e.g. data.items.0.id
header	The header name, e.g. content-type
var	A variable name — read from the active environment for a request test, or from chain scope in an assert node

Operators

op	Meaning
eq	Equals expected
ne	Does not equal expected
contains	expected occurs in the value
gt	Numerically greater than expected
lt	Numerically less than expected
exists	The value is present — expected is unused
matches	The value matches the regular expression in expected

expected is a string, so quote a number in YAML (expected: "201"), and it may itself contain {{variables}}.

Reading the results

The response pane gets a pass/fail strip and a Tests tab listing each assertion with what it expected and what it got. Run history stores results too, with a passed/total pill on the row — so you can see when an endpoint started failing, not just that it fails now.

What is not evaluated

SSE streaming sends do not evaluate tests. A request whose Accept is text/event-stream streams events rather than producing one buffered response, so there is nothing for the assertions to run against.

Keeping YAML clean

An empty test list is dropped rather than written, so a request never gains tests: [] and your diffs stay minimal.

In a chain

The assert node takes the same list. All assertions passing routes to the pass branch; any failure routes to fail — which means a chain can check its own intermediate state and take a different path instead of just stopping.

- id: check-created
  type: assert
  position: { x: 400, y: 120 }
  assertions:
    - source: status
      op: eq
      expected: "201"

A note on scope

This vocabulary — four sources, seven operators — is what v0.1.0-preview.9 ships. If you have read about asserting on response duration, size, or cookies, or about validating a body against the spec’s declared schema, those are later work and are not in this release.