Skip to main content

Variables & templates

Capture a value & reuse it​

Some flows need a value the app generates at runtime — an application ID shown on one page, a confirmation number, a token — fed into a later step (a search box, a URL, an assertion). A Capture step reads a value off the page during replay and stores it in a run-scoped variable you reference later as {{var.NAME}}.

Author a capture​

While recording, click Capture in the toolbar (next to Assert) — it turns blue — then click the element holding the value.

Capture mode active — click the Capture button, then click the value on the page

A small menu lets you choose:

  • Variable — the name you'll reference later, e.g. applicationId (auto-suggested from the element).
  • What to grab — the three extraction kinds:
    • Text — the element's visible/accessible text. For labels, spans, headings, table cells.
    • Input value — an <input> / <textarea> / <select> .value (or a checkbox/radio's checked state).
    • Attribute — a named attribute such as href, data-id, or value. For values that live in markup, not visible text.
  • Extract (regex) — optional. Pull just the part you want out of noisy text. If the pattern has a capture group, group 1 is used; otherwise the whole match. e.g. APP-\d+ turns Application ID: APP-7741 into APP-7741.

Click Capture, and a capture step is recorded — shown in the Events list as capture applicationId ← text .app-id (teal badge).

The capture menu — name a variable, choose what to grab, optionally extract with a regex, then Capture

Reuse the captured value​

In any later input value, navigate URL, or assertion text, reference it as {{var.NAME}}. Open the + Template menu (or type {{) — captured variables appear under a Captured category, so you click to insert; no need to type the var. prefix. The Edit drawer shows the last run's resolved value beneath the field.

The + Template menu in the Edit drawer — captured variables and reusable tokens insert as templates

The value is read fresh on every run — only the instruction (selector + variable + kind) is saved in the .trq, never the value — so it always reflects the current run's data. (The capture step must run before the step that uses it.)

Example​

1.  navigate   https://app.example.com/journey/123
2.  capture    applicationId  ←  text  .app-id        (regex: APP-\d+)
3.  navigate   https://backoffice.example.com/search
4.  input      #search  =  {{var.applicationId}}
5.  click      .search-btn
6.  assert     text-equals  {{var.applicationId}}  on  .result-id

On each run Trq reads the live id (e.g. APP-7742), types it into the back-office search, and asserts the result. Capture works across tabs and cross-origin iframes, and in Play, Resume, and Debug. If a value loads slowly, capture polls until it appears.

Value templates​

Any URL, input value, or assertion text accepts {{…}} templates, resolved fresh each run. Type {{ for inline autocomplete, or use the + Template menu:

  • reusable — {{uuid}}, {{randomNumber}}, {{randomString}}, {{timestamp}} — generated once per run and reused everywhere the same token appears (see below).
  • faker — {{faker.email}}, {{faker.firstName}}, {{faker.phone}}, {{faker.uuid}}, …
  • random — {{random.string(8)}}, {{random.int(1,99)}}, {{random.alpha(6)}}
  • date — {{date.iso}}, {{date.now}}, {{date.future(7)}}
  • env — {{env.MY_VAR}} (reads the environment at run time)
  • var — {{var.NAME}} — a value grabbed earlier by a Capture step or an API request's Extract; appears under the Captured menu category.
  • calc — {{calc(var.x + var.y, 2)}} — arithmetic on captured values, computed fresh each run (see below).

The Edit drawer shows the last run's resolved value beneath each templated field.

Arithmetic on captured values — calc()​

Some assertions are about a derived number: a total that should equal fee + tax, an amount converted at a live rate, a count after adding one. Hard-coding the expected number breaks the moment the inputs change — so compute it instead. {{calc(…)}} evaluates an arithmetic expression over your captured variables at replay time, and works in any templated field (assertion text, input values, URLs, API request bodies).

Inside calc(…), reference variables bare — var.fee, not {{var.fee}} — and combine them with + - * / % and parentheses. An optional trailing integer sets the number of decimal places, so the result string-matches how the page renders it:

Authoring a calc() expression in the Edit drawer — the Math category in the + Template menu inserts a calc skeleton

On each run, the capture steps read the live numbers, and the assertion's expected value is computed from them before comparing against the page:

After Play — capture rows show the numbers they read, and the assert row shows the calc expression resolved to the computed total

1.  navigate   https://app.example.com/journey/123
2.  capture    fee  ←  text  .fee-amount
3.  capture    tax  ←  text  .tax-amount
4.  assert     text-equals  {{calc(var.fee + var.tax, 2)}}  on  .total

Details worth knowing:

  • Captured strings are normalized before parsing — currency symbols (₹ $ € £ ¥), thousands separators, and spaces are stripped, and a trailing unit is tolerated, so ₹ 1,30,110.00 INR parses as 130110.
  • Formatting — {{calc(expr, 2)}} renders with exactly 2 decimals (1416.00); without the places argument, float noise is rounded away (0.1 + 0.2 → 0.3).
  • Failures stay visible — an unknown variable, a non-numeric value, or a division by zero resolves to the literal {{calc(…)}} text, so the assert fails showing exactly which expression didn't compute, instead of silently comparing an empty string.
  • The capture steps must run before the step that uses the expression — same rule as any {{var.NAME}}.

Reusable values — generate once, reuse across steps​

The faker / random / date tokens regenerate on every step, so you can't create something on one page and find it on another. The reusable tokens fix that: they generate a value once per run and return that same value wherever the identical token appears — so you can name an entity in one step and search for it in a later step. A new value is generated on each Play/Resume (so reruns don't collide), stable within that run.

TokenValue
{{uuid}}a v4 uuid
{{uuid(8)}}first 8 hex chars (dashes stripped) — a short id; {{uuid(2,6)}} takes a substring
{{randomNumber}} / {{randomNumber(1000,9999)}}a random integer (default 6 digits)
{{randomString}} / {{randomString(12)}}random alphanumeric (default length 8)
{{timestamp}}run-start epoch milliseconds

Add a :label for a second, distinct value: {{uuid:orderId}} and {{uuid:invoiceId}} generate two different uuids, each reused under its own name.

3.  input    #name     =  page-{{uuid(8)}}      →  page-f03a19e0
4.  click    #create
…
9.  input    #search   =  {{uuid(8)}}           →  f03a19e0   (same value, same run)

{{uuid(8)}} is its own short id — not the first 8 chars of {{uuid}}. For a stable handle reused in several places, use a named token consistently (e.g. always {{uuid:orderId}}).