Function Call Syntax

## One wrapper, two meanings JMeter has exactly one interpolation syntax: `${...}`. Everything between the braces is resolved when the surrounding field is evaluated. If the text names a **variable**, JMeter substitutes that variable's value; if it names a **function**, JMeter runs the function and substitutes what it returns. ``` ${__functionName(arg1,arg2,arg3)} ``` Every function shipped with JMeter begins with a double underscore — `__UUID`, `__counter`, `__RandomString`, `__timeShift`, `__urlencode`, `__P`, `__V`. The prefix is a naming convention rather than a parser rule, and its whole job is to keep built-ins from colliding with names you invent yourself. In practice you can read a reference at a glance: a leading `__` means a call, anything else means a variable lookup. ## Arguments are positional Whatever sits inside the parentheses is split on commas into positional arguments. There are no keyword arguments and no named defaults — position is the only thing that identifies an argument. - `${__RandomString(8)}` — length only. - `${__RandomString(8,abcdef)}` — length, then the pool of characters to draw from. - `${__RandomString(8,abcdef,SUFFIX)}` — length, pool, and a variable to store the result in. A trap worth learning on day one: `${__RandomString(8)}` with no pool draws from the whole of Unicode, so you get eight arbitrary characters rather than eight letters. Almost every real use supplies the second argument. ## Parentheses are optional only when there are no arguments `__UUID` and `__threadNum` declare no parameters, so `${__UUID}` and `${__UUID()}` are equivalent, as are `${__threadNum}` and `${__threadNum()}`. The moment a function takes one argument the parentheses become mandatory. The reverse is not true. *Optional* arguments still occupy positions, so you cannot simply leave the tail off. `__timeShift` accepts four or five parameters and rejects anything shorter, which is why its documented examples read `${__timeShift(,,PT10S,,)}` — the unused slots are still typed out as empty text between commas. ## Names are case-sensitive Functions, variables and properties are all case-sensitive in JMeter. `${__uuid}` and `${__Uuid}` are not the `__UUID` function; they are variable lookups that will almost certainly miss. Variable *names* are trimmed of surrounding spaces before lookup, so `${__Random(1,63, LOTTERY )}` stores into `LOTTERY`, not into a name with spaces around it. ## An unresolved reference is not an error This is the behaviour that catches everyone once: | You write | JMeter resolves | The field receives | | --- | --- | --- | | `${__UUID}` | the `__UUID` function | e.g. `c69e0dd1-ac6b-4f2b-8d59-5d4e8743eecd` | | `${__UUId}` | no such function, no such variable | the literal text `${__UUId}` | | `${ORDER_ID}` before `ORDER_ID` is set | no such variable | the literal text `${ORDER_ID}` | A reference JMeter cannot resolve is handed straight back, and nothing is logged at error level. A typo therefore travels all the way into the request body as literal text instead of surfacing as a start-up failure. The habit that costs nothing: look at one sampler's request tab, or drop in a Debug Sampler, the first time a new field uses a function. ## Where a call can go - Almost any text field of almost any element — sampler paths, body data, header values, timer delays, assertion patterns. - Not usefully on the Test Plan element itself: thread variables are not set up there, so `__threadNum` and the variable-reading functions do not work, while `__P`, `__property`, `__intSum`, `__longSum`, `__time` and the scripting functions do. - Not `__threadNum` inside a config element such as User Defined Variables — config elements are processed from a separate thread. One structural detail explains a great deal of surprising behaviour later: **each occurrence of a call in the plan is compiled into its own function instance.** Two fields that both contain `${__counter(TRUE,)}` do not share a sequence; they are two independent counters that happen to be spelled the same way.