Check displayed

Check displayed

Confirm that an element is visible on the page

The Check Displayed step lets your automated test verify that a specific element is currently visible to the user in the browser view. This is a key part of functional validation because many elements should appear only after certain actions, conditions, or states are met.

Visible elements indicate to users that content has loaded, interactive controls are available, and the interface has responded appropriately to prior steps. By asserting visibility, your automation confirms that the page layout and user experience behave as intended.

Why display checks matter

Just because an element exists in the DOM does not mean that a user can see or interact with it. Developers often use CSS, conditional rendering, or dynamic loading to show or hide content based on interaction or state.

For example:

  • A “Submit” button only appears after a form is complete

  • A modal dialog displays after clicking a trigger

  • A navigation menu shows after hovering or tapping

  • Contextual help appears after user interaction

By validating that an element is displayed, you confirm that the UI has reached the expected state and is ready for the next action or assertion.

How the step works

When you use Check Displayed, your test:

  1. Targets the element using a selector

  2. Verifies that the element is visible in the viewport

  3. Fails the test if it is not displayed

  4. Continues once the condition is satisfied

This gives you precise confirmation that content is not just present in code but visible and accessible to users.

Typical use cases

Display checks are useful in many scenarios, such as:

  • Confirming a success message appears after a form submission

  • Checking that a dropdown has expanded

  • Ensuring that a modal, popup, or toast is visible

  • Verifying that a header, footer, or banner displays correctly

  • Validating that dynamic content loaded after an API call appears

These ensure your automation reflects real user experience.

Combine with other assertions

Visibility checks are often paired with:

  • Touch — to trigger the condition that shows an element

  • Wait for Element — to handle asynchronous loading

  • Check Text — to validate content inside the visible element

  • Visual regression — to compare layout appearance

  • Check Value — for inputs that appear after interaction

This allows you to build robust, real-world coverage of your user journeys.

Confidence in real user behaviour

Seeing is believing. An element that exists but isn’t displayed may mislead scripts or testers. By asserting that an element is truly visible before further actions or validations, you eliminate assumptions and make your test more reflective of a real user’s experience.

This improves test reliability, reduces false positives, and ensures your suite validates both functionality and user perception consistently.