Consider this Cypress test snippet that uses cy.request for programmatic login:
cy.request({
method: 'POST',
url: '/api/login',
body: { username: 'user1', password: 'pass123' }
}).then((response) => {
expect(response.status).to.eq(200)
cy.setCookie('session_id', response.body.sessionId)
})
cy.visit('/dashboard')
cy.get('h1').should('contain.text', 'Welcome user1')What will happen when this test runs?
cy.request({
method: 'POST',
url: '/api/login',
body: { username: 'user1', password: 'pass123' }
}).then((response) => {
expect(response.status).to.eq(200)
cy.setCookie('session_id', response.body.sessionId)
})
cy.visit('/dashboard')
cy.get('h1').should('contain.text', 'Welcome user1')Think about how Cypress commands are queued and asynchronous behavior.
In Cypress, commands like cy.request are asynchronous and queued. However, cy.visit is called immediately after cy.request without chaining. This means cy.visit runs before the login request finishes, so the dashboard loads without authentication, causing the assertion to fail.
You receive this JSON response from a login API:
{"status": "success", "token": "abc123", "user": {"id": 5, "name": "Alice"}}Which Cypress assertion correctly checks the response indicates success and contains a token?
Check the exact property names and types in the response body.
The response body has a status string equal to 'success' and a token string. Option D correctly asserts both conditions using to.eq and to.be.a('string'). Option D uses to.exist which is valid but combined with && is not a Cypress best practice. Option D wrongly expects status to be boolean true. Option D wrongly expects token to be undefined.
After a successful programmatic login, the page shows a message:
<div role="alert" aria-live="polite" class="login-message">Login successful!</div>
Which Cypress selector is best to locate this message for assertion?
Consider accessibility and specificity for reliable selectors.
Option B combines the class selector with the role attribute, making it specific and accessible. Option B is less specific and may match other divs containing the text. Option B selects any element with aria-live polite, which might be too broad. Option B selects by class only, which might match multiple elements.
Test code snippet:
cy.request('POST', '/api/login', { username: 'user', password: 'pass' })
.then((res) => {
cy.setCookie('auth_token', res.body.token)
})
cy.visit('/profile')
cy.get('.profile-name').should('be.visible')Sometimes the test fails because the profile name is not visible. Why?
cy.request('POST', '/api/login', { username: 'user', password: 'pass' }) .then((res) => { cy.setCookie('auth_token', res.body.token) }) cy.visit('/profile') cy.get('.profile-name').should('be.visible')
Think about the order of Cypress commands and their execution.
In Cypress, commands are asynchronous and queued. Here, cy.visit is called immediately after cy.request without chaining inside the then. This causes cy.visit to run before the cookie is set, so the profile page loads unauthenticated, making the profile name invisible and causing the test to fail.
You want to programmatically log in by sending a POST request, set the auth cookie, then visit the dashboard page. Which code snippet achieves this correctly?
Remember to chain commands so they run in the correct order.
Option C chains cy.visit inside the then callback after setting the cookie, ensuring the login completes before visiting the dashboard. Option C calls cy.visit immediately after cy.request, so it runs too early. Option C visits before login, so the page loads unauthenticated. Option C calls cy.setCookie outside then and uses a hardcoded token, which is incorrect.