Tests without code

A test is a check that runs on every response: "the status is 200", "the body has an id", "the answer came back in under half a second". ApiWorkbench has five kinds of test that you fill in like a form. No code is needed.

Add your first test

1. Open a request and select the Tests tab in the request editor.

2. Select Add test. A new row appears, set to Status equals.

3. Type 200 in the value field.

4. Select Send.

5. In the response, open the Tests tab. A green tick means the test passed. A red cross means it failed, and the line under it says what came back instead.

The response tab's label shows the score as passed out of total, for example Tests (3/4). It is green when everything passed and red when anything failed.

Each row has a checkbox. Untick it to switch a test off without deleting it. The Tests tab of the request editor counts the ticked tests, for example Tests (2).

The five kinds of test

Kind	You fill in	Passes when
Status equals	A status code or a class	The status code matches
Body contains	Some text	The text appears anywhere in the body
JSON field equals	A JSON path and a value	The value at that path equals yours
Header contains	A header name and some text	The header has that text in its value
Time below (ms)	A number of milliseconds	The response took less time than that

Status equals

Type the exact code you expect, such as 200 or 201.

To accept a whole family of codes, type a class: 2xx passes for any status from 200 to 299. The classes are 1xx, 2xx, 3xx, 4xx and 5xx. Upper or lower case both work.

Expected	Response status	Result
200	200	Pass: expected 200, got 200
200	201	Fail: expected 200, got 201
2xx	204	Pass: expected 2xx, got 204
4xx	404	Pass: expected 4xx, got 404
ok	200	Fail: "ok" is not a number

New to status codes? See HTTP basics.

Body contains

Passes when your text appears anywhere in the response body. The match is exact: upper and lower case must match, and so must spaces.

That matters for JSON. A server may send "status":"active" or "status": "active" (with a space). If you are checking a JSON value, JSON field equals is the safer choice.

JSON field equals

Checks one value inside a JSON body. You give a path to the value and the value you expect.

A path uses dots for fields and [n] for list items, counting from 0. Take this response:

{
  "data": {
    "total": 2,
    "items": [
      { "id": 42, "name": "Ada", "active": true },
      { "id": 43, "name": "Linus", "active": false }
    ]
  }
}

JSON path	Expected value	Result
data.total	2	Pass
data.items[0].id	42	Pass
data.items[1].name	Linus	Pass
data.items[0].active	true	Pass
data.items[2].id	44	Fail: path "data.items[2].id" not found

Rules to know:

• The value is compared as text. Write strings without quotes: Ada, not "Ada".
• Numbers and booleans are written as they appear in the JSON: 42, true.
• A JSON null matches the expected value null.
• Point the path at a single value, not at an object or a list.
• If the body is not JSON, the test fails with body is not valid JSON.
• When the body is a list at the top level, start the path with the index: [0].id.

See JSON basics if paths are new to you.

Header contains

Checks a response header. Type the header name, then the text its value must contain.

• The header name and the text both ignore case. content-type and Content-Type are the same.
• Leave the value empty to check only that the header exists. The field's hint says value (empty = just exists).
• If the header is missing, the test fails with header "…" is absent.

Example: header Content-Type, value json passes for application/json; charset=utf-8.

Time below (ms)

Passes when the response arrives faster than your limit, in milliseconds. 1500 means one and a half seconds.

The response must be strictly faster: with a limit of 500, a response that takes exactly 500 ms fails. The result line reads took 320 ms (limit 500 ms).

How pass and fail are decided

• Every ticked test runs after every send. Unticked tests are skipped.
• If the request gets no response at all (wrong address, no network, timeout), every test fails with request failed: followed by the error.
• Expected values are compared exactly as you typed them. {{variables}} are not filled in inside a test's fields.
• In the collection runner, the load tester and the command-line runner, a request passes when all its tests pass. A request with no tests passes when its status is below 400.

Where results show

Place	What you see
Response Tests tab	One line per test, with a tick or cross and a message
Collection runner	pass 2 • 200 • 85 ms • 3/3 tests; expand a row for each test
Load tester	Failed calls are counted, with the first failed test as the reason
Command-line runner	Listed under each request, and counted as assertions in the summary

Worked example: check a "create" request

Suppose POST /todos creates a to-do item and answers like this:

HTTP/1.1 201 Created
Content-Type: application/json
Location: /todos/17

{ "id": 17, "title": "Buy milk", "done": false }

Add these five tests:

Kind	Path or header	Value
Status equals		201
Header contains	Content-Type	application/json
Header contains	Location	(empty)
JSON field equals	title	Buy milk
JSON field equals	done	false

Send the request. The response tab reads Tests (5/5). Now change the last expected value to true and send again: the tab turns red, reads Tests (4/5), and the failing line says expected "true", got "false".

To try this against a real API, use the Todo API sample project.

When you need more than this

These tests cover the common checks. For anything else, such as comparing two fields, checking every item of a list or validating a JSON schema, write a short test in a script. Script tests and no-code tests appear together in the same Tests tab.

Next steps

• Captures: chain requests: save a value from one response and use it in the next request.
• Collection runner: run every request and its tests in one go.
• Functional testing: what to check, and why.