In a Karate feature file, what does the expected value `'#? _ > 0'` assert inside a `match`, and what is `_` bound to while that expression runs?

## The marker that runs code Karate's `match` compares an **actual** payload against an **expected** one. Most of the expected side is literals and `#`-prefixed type markers, but when no marker states the rule you need, `#?` lets you write the rule itself: the text after the `?` is a JavaScript expression, and its result is the verdict. ```gherkin * def date = { month: 3, day: 12 } * match date == { month: '#? _ > 0 && _ < 13', day: '#number' } ``` Nothing here is a step definition and nothing is a matcher object. The expected value is an ordinary string; Karate sees that it starts with `#`, splits it at the first `?`, evaluates what follows on the scenario's own JavaScript engine, and passes the node only when the result is `true`. ## The two names Karate injects Just before it evaluates the expression, Karate puts two names into the engine, and removes them again as soon as the expression returns: | Name | Bound to | |---|---| | `_` | the **actual value at this position** — "self" | | `$` | the **root of the actual side** of this `match` step | - `_` is whatever sits under the key the marker is written against. In `{ month: '#? _ > 0' }` it is the value of `month`. - A marker used as the *whole* expected value binds `_` to the whole payload, so `match response == '#? _.length == 3'` judges the response itself. - `$` is the top of the left-hand side of **that statement** — not the response, and not the feature file. `match response.data == { ... }` binds `$` to `response.data`, so a field that sits outside `data` is not reachable from the predicate. `$` is what makes a cross-field assertion possible without lifting values into variables first: ```gherkin * def temperature = { celsius: 100, fahrenheit: 212 } * match temperature contains { fahrenheit: '#? _ == $.celsius * 1.8 + 32' } ``` ## Scenario variables are in scope The expression runs on the scenario's engine, so anything `def`-ed is visible to it — bounds, lookup tables, and functions: ```gherkin * def min = 1 * def max = 12 * match date == { month: '#? _ >= min && _ <= max' } * def isValidTime = read('time-validator.js') * match entry == { at: '#? isValidTime(_)' } ``` Pushing anything longer than one line into a `def`-ed function keeps the expected payload readable and makes the rule reusable across features. The function receives the value under test as its argument and returns a boolean. ## Combining a type check with a rule A validator name may sit in front of the `?`, and then **both** checks run — the validator first, the expression only if the validator passed: 1. `'#? _ > 0'` — no type check at all, so JavaScript coercion decides and the string `'3'` passes. 2. `'#number? _ > 0'` — the number validator runs first and rejects anything that is not a number, then the expression runs. 3. `'#string? _.startsWith("SKU-")'` — the same shape for strings. The combined form is usually the one you want: it pins the type and the business rule in a single expected value, and it is one of the reasons Karate never needed a separate schema language. ## What a failure looks like A predicate that returns false fails the step with `evaluated to 'false'`, and the report prints the JSON path of the offending node next to the actual value and the marker string. Because the marker is data inside the payload, that path is exact even for a rule buried several levels down — there is no stack of assertion helpers standing between the failure and the field. ## Return a boolean, not a truthy value Write the comparison out. Karate 1.5.2 requires a genuine boolean: its internal truth test accepts only a `Boolean`, so `'#? _.length'` fails against a three-element array even though JavaScript would call that value truthy. Karate 2.x evaluates full JavaScript truthiness and the same expression passes. `'#? _.length == 3'` says what you mean and is correct on both lines, so make the comparison explicit and the question never arises. ## Where it fits Reach for `#?` when the expectation is a **rule** rather than a value or a type — a range, a relationship between two fields, a format the built-in validators do not cover, a membership test against a list you loaded. Reach for a plain literal when the value is known and fixed, and for a type marker when only the shape matters. Mixing all three inside one expected payload is the point of the design: one step, one failure report, and no assertion code to maintain beside the test.