Cypress architecture (runs in browser) - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Where does Cypress test code run?

In Cypress architecture, where does the test code execute?

A Only on the Node.js server outside the browser

B In a separate virtual machine isolated from browser and server

C Inside the browser alongside the application code

D On a cloud server managed by Cypress

💡 Hint

Think about how Cypress interacts with the web page it tests.

Cypress runs test code inside the browser, in the same environment as the application. This allows it to directly control and observe the app.

❓ Predict Output

intermediate

Cypress command execution order

What will be the order of console logs when running this Cypress test?

Cypress

describe('Test order', () => {
  it('logs messages', () => {
    cy.log('A')
    console.log('B')
    cy.log('C')
    console.log('D')
  })
})

A A, C, B, D

B B, D, A, C

C A, B, C, D

D B, A, D, C

💡 Hint

Remember that cy.log commands are asynchronous and queued, while console.log runs immediately.

Console logs run immediately in the browser, so 'B' and 'D' appear first. Cypress commands like cy.log are queued and run later, so 'A' and 'C' appear after.

❓ assertion

advanced

Correct assertion for element visibility in Cypress

Which assertion correctly checks that a button with id submit-btn is visible?

A cy.get('#submit-btn').should('be.visible')

B cy.get('#submit-btn').should('exist')

C cy.get('#submit-btn').should('have.text', 'Submit')

D cy.get('#submit-btn').should('not.be.hidden')

💡 Hint

Visibility means the element is shown on the page, not just present in the DOM.

be.visible asserts the element is visible to the user. exist only checks presence in DOM. have.text checks text content. not.be.hidden is valid, but be.visible is the standard assertion.

🔧 Debug

advanced

Why does this Cypress test fail to find element?

Given this test code, why does Cypress fail to find the element?

Cypress

it('fails to find element', () => {
  cy.visit('/page')
  cy.get('.dynamic-item').click()
})

A cy.visit() does not load the page before cy.get() runs

B The selector '.dynamic-item' is invalid CSS syntax

C cy.get() only works for elements with IDs, not classes

D The element is added dynamically after page load, but no explicit wait or retry is used

💡 Hint

Think about how Cypress waits for elements and when elements appear.

Cypress retries cy.get() for a short time, but if the element is added after that or requires waiting, the test fails. The selector is valid, cy.visit() waits for page load, and cy.get() works with any selector.

❓ framework

expert

How does Cypress architecture enable automatic waiting?

Which architectural feature of Cypress allows it to automatically wait for commands and assertions without explicit waits?

A Cypress runs inside the browser and controls the event loop to retry commands until success or timeout

B Cypress uses a separate server to poll the application state continuously

C Cypress injects custom JavaScript timers to delay commands manually

D Cypress requires user to add explicit <code>cy.wait()</code> calls for synchronization

💡 Hint

Think about how Cypress integrates with the browser environment.

Cypress runs inside the browser and hooks into the event loop, allowing it to retry commands and assertions automatically until they pass or timeout. This removes the need for manual waits.