In k6, how do you call check() from the k6 module, and what does each argument do?

## What `check()` is and where it comes from k6 ships a small built-in module named `k6`. In k6 v2 that module exports exactly five names — `check`, `fail`, `group`, `randomSeed` and `sleep` — and `check` is the only condition-testing primitive the binary contains. You reach it with a named import: ```javascript import { check } from 'k6'; ``` There is no global `check`, so the import is mandatory. There is also no `expect()` anywhere in the k6 binary; that name belongs to a separately imported library, not to the runtime. ## The signature: `check(val, sets, [tags])` | argument | required | what it holds | |---|---|---| | `val` | yes | the value under test — commonly an HTTP response object, but any JavaScript value is accepted | | `sets` | yes | an object whose **keys are the check names** and whose **values are the conditions** | | `tags` | no | a flat `{key: value}` object of extra tags attached to the results this one call produces | The call returns a **boolean**: `true` when every entry in `sets` evaluated truthy, `false` otherwise. It is an ordinary value you can assign, log or branch on. ## How k6 reads the `sets` object k6 walks the own keys of `sets` in order, and for each key: 1. **The key becomes the check's name**, character for character. That name is the check's identity in the run's results, so write it as a statement about the system — `'login status is 200'`, never `'check1'`. 2. **If the value is a function**, k6 calls it with exactly one argument — the `val` you passed first — and uses what it returns. The function is invoked with `this` undefined, so a non-arrow function cannot rely on `this`. 3. **If the value is not a function**, k6 uses it as it stands. `check(res, { 'ok': res.status === 200 })` is legal; JavaScript simply evaluated that expression while building the object literal, before `check()` was entered. 4. **The result is coerced with ordinary JavaScript truthiness** and recorded as a pass or a fail under that name. Because the value under test is handed to the predicate, these two styles behave identically: - `check(res, { 'status is 200': (r) => r.status === 200 })` — the parameter `r` **is** `res`. - `check(res, { 'status is 200': () => res.status === 200 })` — the closure reaches `res` directly. The predicate is plain JavaScript executed synchronously in the same VU runtime as the rest of the iteration. There is no sandbox and no separate context: whatever the surrounding script can see, the predicate can see. ## The worked case: validating a login response ```javascript import http from 'k6/http'; import { check } from 'k6'; export default function () { const res = http.post('https://example.com/login', JSON.stringify({ user: 'alice' }), { headers: { 'Content-Type': 'application/json' }, }); const ok = check(res, { 'login status is 200': (r) => r.status === 200, 'login body has a token': (r) => r.json('token') !== null, }); if (!ok) { // your own handling; check() itself stopped nothing } } ``` One value, two named conditions, one boolean back. Naming both conditions separately rather than combining them with `&&` is what makes the results readable: a single entry that ANDs status and body can only tell you that something was wrong, never which half. ## Two contract rules that bite immediately - **`check()` requires VU state.** Calling it at module scope — the init context, where imports run and `options` is defined — fails with *"Using check() in the init context is not supported"*. Conditions belong inside the exported default function or another `exec` target. - **A check name may not contain `::`.** k6 reserves `::` as the separator inside group paths, so any name containing it is rejected outright with *"group and check names may not contain '::'"*. Two smaller consequences of `sets` being an ordinary JavaScript object are worth knowing. A repeated key silently overwrites the earlier one, so two entries in one call can never share a name. And calling `check()` with no second argument at all fails with *"no checks provided to `check`"* rather than passing vacuously. The same object-ness has a stranger consequence: an **array** is a valid `sets` argument, because an array's own keys are its indices. `check(res, [(r) => r.status === 200])` runs happily and records a check named `0`. It is legal and almost never what you want — the name is the only human-readable thing a check result carries, and an index is not one.