End-to-End Testing with Cypress: Beginner Essentials Quiz

Explore key concepts of end-to-end testing with Cypress through practical scenarios and essential techniques. This quiz helps beginners strengthen their automated test skills, covering test structure, selectors, best practices, and common pitfalls in Cypress-based workflows.

1. Cypress Initialization

   When setting up an end-to-end test with Cypress, which file is typically responsible for defining reusable commands and custom logic globally available to all test files?

   1. helper.css
   2. config.ts
   3. commands.js
   4. runner.yaml

   Explanation: The commands.js file is commonly used to define reusable commands and custom logic, making them accessible throughout all Cypress test files. config.ts is not used for defining commands; it is more suited for configuration tasks. runner.yaml is not a standard file in Cypress and would not contain commands. helper.css is a style sheet file and irrelevant to defining test logic.

2. Best Practices with Selectors

   In a scenario where you need to reliably select a button element for interaction in an automated test, which selector strategy is considered best practice to ensure test stability?

   1. Locating the element by its class name
   2. Selecting the element by its text content
   3. Using a unique data attribute
   4. Targeting the element by its color style

   Explanation: A unique data attribute, such as data-cy, provides a stable selector that does not change with UI updates, making tests more robust. Selecting by text content or class name can be fragile if either is changed for design reasons. Targeting by color style is highly unreliable, as style changes are frequent and unrelated to functionality.

3. Assertion Methods

   While verifying that a modal appears after clicking a 'Show Modal' button, which Cypress assertion method would appropriately check for the modal’s visibility?

   1. should('contain.value')
   2. should('be.visible')
   3. should('not.exist')
   4. should('have.class', 'hidden')

   Explanation: The should('be.visible') assertion confirms that the modal is displayed and visible on the page, matching the requirement. should('contain.value') is used for input elements and does not apply to modal visibility. should('have.class', 'hidden') would incorrectly assume the modal should remain hidden. should('not.exist') would confirm absence, which is contrary to the purpose of the test.

4. Handling Asynchronous Behavior

   If a button click triggers data to load asynchronously into a table, which Cypress command ensures your test waits for the table to contain the expected text?

   1. cy.waitFor()
   2. cy.sleep()
   3. cy.insert()
   4. cy.contains()

   Explanation: cy.contains() is used to search the DOM for a specific element with the given text and automatically retries until it becomes available, effectively handling asynchronous content. cy.waitFor() is not a valid command. cy.sleep() introduces a fixed delay rather than waiting for a dynamic condition. cy.insert() does not exist in Cypress and would not be appropriate here.

5. Managing Test State

   Which approach helps ensure each Cypress test runs independently without being affected by the state left over from previous tests?

   1. Skipping reset steps for faster runs
   2. Using random sleep intervals
   3. Cleaning up state in beforeEach hooks
   4. Relying on shared test data

   Explanation: The beforeEach hook allows you to reset or clean up the state before every test, ensuring tests do not interfere with each other and produce reliable results. Relying on shared test data risks introducing dependencies between tests. Random sleep intervals do not address cleanup or state management. Skipping reset steps may speed up runs but undermines test isolation and reliability.