Interacting with Elements (type, click, check)
Cypress ships commands that mirror how a real user interacts with a page: cy.type() simulates keystrokes into a focused input, cy.click() simulates a mouse click, and cy.check()/cy.uncheck() toggle checkboxes and radio buttons. Rather than programmatically setting a form field's value, these commands dispatch real DOM events, so your tests exercise the same event handlers — onKeyDown, onClick, onChange — that a genuine user interaction would trigger.
Cricket analogy: A batting coach doesn't just watch video analysis; he has the batter physically face real deliveries in the nets to simulate match conditions, similar to how cy.click() and cy.type() physically simulate a real user's mouse and keyboard actions rather than just injecting values.
Actionability Checks Before Every Action
Before firing an interaction, Cypress runs a series of actionability checks: the element must be visible, not disabled, not covered by another element, and within the viewport (Cypress scrolls it into view automatically if needed). If any check fails, Cypress retries until the element becomes actionable or the command times out, surfacing a clear error describing exactly which check failed.
Cricket analogy: Before allowing a bowler to bowl, the umpire checks the run-up is clear, the field is set, and no one is in the way, similar to how Cypress checks that an element is visible, not disabled, not covered, and within the viewport before firing a click.
cy.get('#email').type('user@example.com');
cy.get('#password').type('Secret123!');
cy.get('form').submit(); // or cy.get('.submit').click();Typing, Clearing and Special Character Sequences
cy.type() supports special character sequences wrapped in curly braces, like {enter} to submit a form, {selectall} to select existing text, or {backspace} to delete a character, letting tests simulate realistic keyboard interactions beyond plain text entry. Because type() appends to existing content by default, it's common to call cy.get(selector).clear().type('new value') first, to guarantee the field starts empty rather than accumulating leftover text from a previous state.
Cricket analogy: A batter clears his mind and resets his stance before facing a fresh over, similar to how cy.get('#search').clear().type('cricket scores{enter}') clears the existing input value before typing fresh text and submitting with the Enter key sequence.
Common special sequences: {enter} submits a form or triggers a keydown handler, {selectall} selects all text in the field, {backspace} deletes the previous character, and {esc} dispatches an Escape keydown — useful for closing modals or dropdowns during a test.
Checkboxes, Radios and Selects
cy.check() and cy.uncheck() are purpose-built for checkbox and radio <input> elements; calling them on any other element type throws an error, since Cypress can't meaningfully 'check' a text field or a div. For <select> dropdowns, use cy.select('Option Label') or cy.select('optionValue') instead, which picks an option by its visible text or underlying value attribute.
Cricket analogy: An umpire can only raise the finger for genuine dismissal modes like lbw or caught, not invent a new one, similar to how cy.check() only works on checkbox and radio inputs and throws an error if used on any other element type.
cy.click({ force: true }) bypasses actionability checks like visibility and overlap detection. It can be a useful escape hatch for known edge cases, but reaching for it routinely often masks a real bug — like a modal overlay blocking clicks in production — that your test should actually be catching.
- Cypress's interaction commands (type, click, check, select) dispatch real DOM events rather than setting values programmatically.
- Before acting, Cypress verifies the target element is visible, enabled, uncovered, and in the viewport.
- type() supports special sequences like {enter}, {selectall}, and {backspace} for realistic keyboard simulation.
- clear() empties a field before typing to avoid leftover text from a prior state.
- check()/uncheck() work only on checkbox and radio inputs; select() is used for <select> dropdowns.
- force: true bypasses actionability checks and should be used sparingly, since it can hide real UI bugs.
Practice what you learned
1. How does cy.click() differ from directly setting a DOM element's state via JavaScript?
2. Which of these is NOT one of Cypress's actionability checks before a click?
3. What does the {enter} sequence do inside cy.type('text{enter}')?
4. Why call .clear() before .type() on an input?
5. What command should you use to pick an option from a <select> dropdown?
Was this page helpful?
You May Also Like
Selecting Elements with cy.get()
Learn how Cypress's cy.get() command queries the DOM using CSS selectors, and how to choose selectors that are stable, readable, and resistant to markup changes.
Chaining and Retry-ability
Understand how Cypress commands chain together via the command queue and how built-in retry-ability makes assertions resilient to asynchronous UI changes.
Assertions with should() and expect()
Learn the difference between Cypress's retrying should()/and() assertions and Chai's one-time expect() assertions, and when to use each.