Which keyboard interactions in a Cypress suite justify cy.press() over .type() or .trigger()?

Every suite eventually has to decide how much of its keyboard testing goes through the browser and how much is synthesized inside the page. Cypress makes both available — `cy.press()` for the first, `.type()` and `.trigger()` for the second — and leaving the choice to whoever writes the next test produces a suite that is expensive in the places it does not need to be and hollow in the places it does. ## What each mechanism actually proves - **`.trigger('keydown', { key: 'Escape' })` proves a handler runs.** The event is constructed in the page and dispatched at an element you name. If the application listens, the listener fires. The browser is not consulted and applies no default behaviour. - **`.type('AC-4471')` proves text entry works**, including the input events and the value the field ends up with, again from inside the page. - **`cy.press(Cypress.Keyboard.Keys.TAB)` proves the browser does something.** The key leaves the page, the browser dispatches a genuine event to whatever holds focus, and its own default behaviour applies — focus moves, a focused button activates on Enter, a dialog closes on Escape. The distinction that matters: a simulated event can pass on a control a real user can never reach. A `div` with a `keydown` listener and no `tabindex` answers `.trigger()` perfectly and is invisible to the keyboard. The native path fails that test, correctly, until the element is genuinely focusable. ## What the native path costs | Consideration | `cy.press()` | `.type()` / `.trigger()` | |---|---|---| | Target | whatever has focus | an element you query | | Yields | `null` — assert with a fresh query | the subject, chainable | | Modifiers | none | `{ctrl}c`, `{shift}b` | | Long text | rejected — single keys only | its purpose | | Browser coverage | needs a native-key channel; throws in WebKit runs | works wherever the spec runs | | Side effects | puts the page in transient activation | none beyond the dispatched event | The transient-activation point is the one that surprises people. Dispatching real key events puts the page into the same activated state a genuine user interaction produces; if the application under test cancels the default behaviour of `beforeunload`, a subsequent navigation can behave differently than it does under simulated events. ## Where to draw the line A workable convention for a bank statement application, in priority order: 1. **Native for whole keyboard journeys that a user must be able to complete.** Tabbing from the account picker through the date range to the Download PDF button and activating it with Enter is one test, run natively, and it is the test that would catch an unreachable control. 2. **Native for browser-decided behaviour.** Escape closing the statement preview, Enter submitting the focused control, arrow keys moving through a listbox the browser owns. 3. **Simulated for content.** Typing a customer reference, a date, a search term. Nothing about the browser is under test there, and `.type()` is faster and targeted. 4. **Simulated for handler-level checks.** A shortcut key on a component you are testing in isolation does not need the browser's involvement to prove the handler fires. 5. **Nothing native purely for realism.** Converting a passing `.type()` test to `cy.press()` because it is "more real" buys no coverage and costs browser portability. ## The organisational part Two decisions belong to whoever owns the suite, not to the individual test author: - **Browser matrix.** If any spec uses `cy.press()`, that spec cannot run everywhere. Either the matrix shrinks for those specs, or they are guarded — `Cypress.isBrowser()` reads the current family — so the rest of the suite still runs on every browser you support. Guarding is honest; letting them fail is not. - **How many native journeys.** These tests are the slowest and most brittle keyboard tests you will own, because they depend on real focus order that changes whenever the DOM order changes. A small, named set of them is an asset. Sprinkling native key presses through fifty specs turns every layout change into a broad, low-signal failure. ## How to argue it in an interview The strong answer names the trade rather than picking a side: **native key events buy you the browser's own behaviour, and you pay for them in portability, targeting and maintenance.** Then it gives the rule — a handful of deliberate end-to-end keyboard journeys go native, everything else stays in the page — and says how the exceptions are guarded. The weak answer is either "always use `cy.press()`, it's more realistic" or "`.trigger()` is fine, the handler runs". Both discard half the information.