Cypress Form Assertions

Asserting on Form State

Beyond simply typing into fields, real form tests need to confirm the resulting state: does an input hold the expected value, is a checkbox checked, is a submit button correctly disabled until required fields are filled.

cy.get('[data-cy="email"]').type('user@example.com');
cy.get('[data-cy="email"]').should('have.value', 'user@example.com');

cy.get('[data-cy="terms"]').check();
cy.get('[data-cy="terms"]').should('be.checked');

cy.get('[data-cy="submit"]').should('not.be.disabled');

Each assertion confirms the form reached the expected state after an interaction, not just that the interaction command ran.

Form Assertion Syntax

.should('have.value', 'text')
.should('be.checked')
.should('not.be.checked')
.should('be.disabled')
.should('not.be.disabled')
.should('have.attr', 'required')

• have.value checks an <input>, <textarea>, or <select>'s current value.
• be.checked/not.be.checked applies to checkboxes and radio buttons.
• be.disabled/not.be.disabled checks whether a field or button is interactive.
• have.attr('required') confirms a field is marked required in the markup.

Form Assertions Cheat Sheet

Common checks for verifying form field state after user interaction.

Testing Client-Side Validation Messages

Client-side validation typically shows an error message and/or an "invalid" styling class after a failed submission attempt. Testing this end-to-end (rather than only via unit tests) confirms the whole feedback loop, form submit, validation trigger, message render, works correctly together.

cy.get('[data-cy="signup-form"] [data-cy="submit"]').click();
cy.get('[data-cy="email-error"]')
  .should('be.visible')
  .and('contain', 'Email is required');
cy.get('[data-cy="email"]').should('have.class', 'is-invalid');

Testing Progressive Enable/Disable Behavior

Many forms disable a submit button until all required fields are valid. Testing both states, disabled before completion, enabled after, confirms the enabling logic itself, not just the final successful submission.

cy.get('[data-cy="submit"]').should('be.disabled');
cy.get('[data-cy="email"]').type('user@example.com');
cy.get('[data-cy="password"]').type('SecurePass123!');
cy.get('[data-cy="submit"]').should('not.be.disabled');

This pattern verifies the button's enabled state transitions correctly as required fields are completed.

Native Browser Validation vs. Custom Validation

Native HTML5 validation (via the required or pattern attributes) shows browser-native tooltips that Cypress cannot easily inspect as regular DOM content. Many applications instead implement custom JavaScript validation with visible error elements, which is far easier and more reliable to assert on directly.

• Prefer testing custom, DOM-rendered validation messages when your app implements them.
• For native browser validation, check the input's validity property via .then() if a direct assertion is truly required.
• Confirm which validation approach your application actually uses before writing the test.

Common Mistakes

• Trying to assert directly on native browser validation tooltip text as if it were normal DOM content.
• Only testing the successful submission path and never asserting on validation error states.
• Forgetting to test that a submit button re-enables correctly once previously invalid fields are fixed.
• Asserting on a value immediately after .type() without confirming the type action actually completed first.

Key Takeaways

• Form assertions confirm the resulting state after interaction, not just that an action command ran.
• have.value, be.checked, and be.disabled cover most common form field state checks.
• Testing validation error messages and progressive button enabling closes real coverage gaps.
• Native browser validation tooltips need a different approach than custom, DOM-rendered validation.