Karate

The method step sends it. The url, path and request steps only accumulate state on Karate's request builder; method is what fires the call. The status step then asserts the response code and fails if it is anything else.

Nothing changes. Karate accepts six step prefixes - the bare asterisk plus Given, When, Then, And and But - and treats all six identically. The prefix never reaches the code that decides what a step does; it is read back only afterwards, by the report and the rest of the output.

In Karate, <name> is a text substitution: the raw cell text is spliced into the step before it runs. '#(name)' is an embedded expression evaluated at run time against the bound variable, so the value keeps its type.

Karate treats an Examples table as dynamic only when it is a single cell: one column and one row, the header, with nothing under it. That cell is evaluated as JavaScript and must return a list of objects or a generator function.

A trailing ! on a Karate Examples column header makes each cell evaluate as a JavaScript value — number, boolean, or inline JSON. Without it the cell stays a plain string, and a blank cell becomes null.

Karate's contains asserts a subset. Against a JSON object, every expected key must exist with an equal value while extra actual keys are ignored. Against a JSON array, every expected item must appear somewhere, in any order.

Karate's match == compares the entire payload in one recursive step: every key and value must correspond exactly. An extra role key fails the step, because == is a strict whole-payload comparison, not a subset check.

The left side of a Karate match step is a variable name, a JsonPath or XPath rooted at a variable such as response.name, a function or method call, or parenthesised JavaScript. A bare $ stands for the response, and a left side that starts with / is a bare XPath rooted there too.

Put marker strings where the unpredictable values would go: match response == { id: '#uuid', createdAt: '#string', name: 'Billie' }. A marker asserts the value's type or shape instead of its content, so one step still checks every key.

#? runs the JavaScript that follows it and passes only when the result is true. Karate binds _ to the actual value at that position, so '#? _ > 0' asserts that the value there is greater than zero.

callonce runs the called feature only the first time and caches what it returned, so every later scenario in that feature file reuses it. Plain call re-executes the login for every scenario and every Examples row.

karate-config.js holds a JavaScript function that returns a map. Karate evaluates it before every top-level scenario and applies each key of that map as a scenario variable, so no step-definition or glue class is involved.

configure headers sets a default header map that Karate re-applies to every later request in scope. The header step sets one header on the request being built, and Karate clears it as soon as that call completes.

The def assignment decides scope. A bare call read('login.feature') merges every variable the called feature defined into the caller; def auth = call read('login.feature') isolates the call and hands those variables back as a map instead.

callonce caches per feature and keys on the call expression exactly as written. karate.callSingle() caches per suite, so once for the whole run across every feature, and keys on the path string you pass it.

Once, when the mock server starts. Karate executes a mock feature's Background while the handler is being built, before the first request arrives; every request afterwards runs only the steps of the one Scenario whose name matched.

In a Karate mock feature the Scenario name is a JavaScript expression evaluated per request, not a label. Scenarios are tried in file order; the first one returning true answers, and if none does the mock replies 404.

A mock scenario returns nothing. It assigns ordinary variables — response, responseStatus, responseHeaders, responseDelay — and after the last step Karate reads them and assembles the reply, so declaration order does not matter.

In a map of global variables owned by the mock handler. The Background seeds it once at start-up, and after every matched Scenario the handler copies that request's variables back, so a def inside a Scenario survives too.

It matches a request path of exactly two segments whose first is literally cats, capturing the second under the name id. On a successful call the helper fills the pathParams map, so the scenario body reads pathParams.id as a string.

In Karate the test is a .feature file whose steps are the framework's own keywords, so there is no step-definition layer to write: the HTTP call, the request payload and the assertion all live in that one file.

Runner.path() opens Karate's builder, each chained call sets one option, and parallel(n) is the terminal call that discovers the features, runs them on n threads and returns a result object. No glue package is involved.

Every compile-time guarantee goes: a Karate step is text and its expressions are JavaScript, so variable, field and method names are unchecked until the scenario runs. Karate replaces them with runtime failure and Java.type.

That chain runs scenarios tagged @smoke or @sanity but not @wip. Separate arguments are ANDed, a comma inside one argument means OR, and a leading tilde negates that whole argument.

Karate's @Karate.Test is a method-level annotation meta-annotated with JUnit's @TestFactory. The method must return a Karate instance, an Iterable of dynamic nodes, so each feature and scenario becomes its own test.