What are the three ways to call Cypress's `cy.intercept()`, and what does each match?

`cy.intercept()` registers a **route** — a description of the network requests a Cypress test cares about. Everything you pass *before* the optional response argument is matching: it decides which of the weather dashboard's requests belong to this route. Cypress accepts that description in three shapes, plus one merge form. ## The three signatures | Signature | Example | What it matches | | --- | --- | --- | | `cy.intercept(url)` | `cy.intercept('/api/forecast*')` | that URL on **every** HTTP method | | `cy.intercept(method, url)` | `cy.intercept('GET', '/api/forecast*')` | that URL, restricted to `GET` | | `cy.intercept(routeMatcher)` | `cy.intercept({ method: 'GET', pathname: '/api/forecast' })` | every property set on the object, ANDed | The `url` argument is a **string glob** or a **`RegExp`** — never a plain substring. A string is first compared for equality, then glob-matched (Cypress uses the minimatch library with `{ matchBase: true }`, exposed to you as `Cypress.minimatch`) against the **full request URL**, and finally against the **request path** as a fallback. That fallback is why a host-less pattern such as `/api/forecast*` matches `https://weather.example.com/api/forecast?station=KSEA`, `http://localhost:8080/api/forecast?station=KSEA`, and the same route on staging. Cypress reads the first argument as a method only when it genuinely **is** one — `GET`, `POST`, `PUT`, `PATCH`, `DELETE`, `HEAD`, `OPTIONS`, and `QUERY`, which Cypress added in 15.20.0. So `cy.intercept('/api/stations', handler)` is unambiguously the `(url, handler)` overload. ## Why leaving the method out bites A method-less route is the widest thing you can register, and on a dashboard where one path serves several verbs it quietly catches more than you meant: ```js cy.intercept('/api/alerts*') // spies on GET /api/alerts?station=KSEA // ...and on POST /api/alerts, when the user dismisses an alert ``` - Add the method whenever a path serves more than one verb. - A method-less route is fine, and often preferable, when the path is read-only. - In the object form, `method` is a string matcher too, so `method: '+(PUT|PATCH)'` — a minimatch alternation group — or a `RegExp` both work. Those only work inside a `routeMatcher`; the `(method, url)` overload accepts real HTTP method names only. ## The routeMatcher object Every property is optional and **all the ones you set must match**; they are ANDed together, and properties you leave out are simply not consulted. The object is where you match on things a URL string cannot express: - `method`, `url` — the same two things the short signatures set. - `path` (everything after the hostname, query string included) and `pathname` (the same, without the query string). - `hostname`, `port` (a number or an array of numbers), `https` (a boolean). - `query` and `headers` — dictionaries whose *values* are themselves globs or regular expressions. - `auth` — the username and password from HTTP Basic credentials. - `middleware` and `times`, which change **when** and **how often** the route is consulted rather than what it matches. - `resourceType`, deprecated since Cypress 14. Two validation rules are worth committing to memory, because both fail loudly rather than silently: 1. `cy.intercept({})` throws — *"The RouteMatcher does not contain any keys. You must pass something to match on."* There is no "match everything" empty object. 2. An unrecognised property throws and prints the valid list, so a typo such as `pathName` surfaces immediately instead of matching nothing. ## The merge form There is a fourth call shape that layers extra matcher fields onto a URL: ```js cy.intercept('/api/forecast*', { middleware: true }, (req) => { /* ... */ }) ``` `cy.intercept(url, routeMatcher, handler)` merges the two matchers, so the object must **not** also carry a `url` key, and the handler is **required** as the third argument — passing only two arguments here throws rather than registering a spy. ## Choosing between them 1. Reach for `cy.intercept(method, url)` by default: it is the shortest thing that says which verb and which path, and it reads well in a spec. 2. Move to the object when the URL alone is ambiguous — two calls to `/api/forecast` that differ only by a `query` parameter, or a poller you want to separate by a request header. 3. Prefer `pathname` plus `query` over a long full-URL glob once the query string carries encoded values; the glob has to get every character right, while `pathname` never sees the query string at all. All intercepts are cleared before every test, so each of these is registered fresh per test and nothing you match in one spec leaks into the next.