In a Karate mock feature file, what is the text after `Scenario:` used for, and what does the mock return when no `Scenario` matches the incoming request?

## A name that is code In an ordinary Karate test the words after `Scenario:` are documentation. In a feature served as a mock they are the routing table. The mock handler reads each `Scenario` name as a JavaScript expression and evaluates it against the request that has just arrived. The body of the scenario says what to reply; the **name** says whether to reply at all. That single design choice is why Karate needs no mapping DSL, no matcher builder and no registration API to stand a service up — the file *is* the router. ## The dispatch loop For every incoming request the handler does the same five things: 1. Puts the request in scope as variables — `request`, `requestPath`, `requestUri`, `requestMethod`, `requestHeaders`, `requestParams`, `requestBytes` — and registers the matcher helper functions (`pathMatches`, `methodIs`, `typeContains`, `paramValue`, `bodyPath` and friends). 2. Walks the served features **in the order they were supplied** to the server. 3. Inside each feature, walks the `Scenario` sections **top to bottom**, evaluating each name as JavaScript. 4. Stops at the first name that evaluates to boolean `true`, runs that scenario's steps, and builds the response out of the variables those steps set. 5. Returns immediately — no later scenario, and no later feature, is consulted for that request. Because step 5 returns, matching is genuinely **first-wins and not best-wins**. Two scenarios can both be true for one request and the second will never know it. ## The catch-all A `Scenario:` line with nothing after it produces an empty matcher expression, and the handler special-cases that: an empty expression is treated as *always matches* and the scenario is selected without evaluating anything. That is the idiom for a catch-all, and it is only useful in one place — **last**. Put it first and it swallows every request in the file, which is the single most common way a Karate mock appears "broken". ```gherkin Scenario: pathMatches('/cats/{id}') && methodIs('get') * def response = cats[pathParams.id] Scenario: pathMatches('/cats') && methodIs('post') * def response = { id: 1 } * def responseStatus = 201 Scenario: # nothing matched above - own the failure instead of letting the handler 404 * def response = { error: 'no route', path: '#(requestPath)' } * def responseStatus = 404 ``` ## What happens when nothing matches If every name evaluates to something other than `true`, the handler logs a warning — *no scenarios matched, returning 404* — and replies with status **404**. Two consequences are worth carrying into an interview: - The 404 is the **mock's** 404, not your modelled "resource not found". A test that asserts `status 404` can pass because the mock routed nothing at all. If the service under test is meant to distinguish those cases, give the catch-all a distinctive body so the difference is visible. - Nothing throws. A request that matches no scenario is not an error condition for the mock, so the only trace is that one warning line in the mock's log. ## Ordering is the only lever It is worth being explicit about what Karate deliberately does **not** give you here: - there is no priority or weight on a `Scenario`; - there is no "most specific match" ranking; - there is no separate default-response setting — the empty-name scenario *is* that mechanism; - tags do not participate in mock routing. So the layout rules are simple and mechanical: narrow matchers above broad ones, the broadest above the catch-all, and the catch-all last. A scenario whose name is just `methodIs('post')` sitting at the top of a file will answer every POST to every path, whatever you wrote below it. ## Multiple feature files One mock server can serve several feature files at once. They are evaluated in the order they were supplied, so the same shadowing rule applies one level up: the first feature that contains a matching scenario answers, and swapping the order of two files on the command line or in the builder can change which stub answers. Keep at most one catch-all across the whole set, in the file you intend to be last. ## Why interviewers ask it The question separates people who have only read a mock feature from people who have debugged one. The reading is intuitive — it looks like a list of test cases with descriptive names. The mechanism is not: those names are executed, on every request, in order, and the first `true` ends the search.