Cypress auth strategies: UI login vs programmatic session
Tests your grasp of Cypress test isolation and speed tradeoffs. A strong answer contrasts slow UI login (ideal for the auth flow itself) against programmatic auth via cy.request or cy.session (fast setup for protected routes).
What's really being asked
Whether you know the difference between testing a feature and setting up state. Interviewers want to see you prioritize fast, isolated tests while still validating critical user paths. They also check if you handle secrets properly and know modern Cypress commands like cy.session.
The full answer
Four strategies in order. First, full UI login where you type credentials and click through the form. Use this sparingly, ideally in dedicated login specs, because it is slow, often 3 to 10 seconds per test, and adds flakiness. Second, programmatic login via cy.request to your auth API. This returns a token or cookie that you inject into the browser, cutting setup time to milliseconds. Third, direct state injection by writing to localStorage or calling cy.setCookie when you already know the session shape. Fourth, cy.session, the modern Cypress best practice that caches the authenticated browser state and restores it instantly across tests while still validating it once. Also mention secrets: use cy.env() for tokens and passwords, never hardcode them, and avoid Cypress.expose() for sensitive data since it leaks values to the browser context.
The mistakes people make
Insisting that every protected route test must start at the login page to be realistic. Hardcoding passwords or tokens in test files. Not knowing cy.session and instead writing custom localStorage hacks. Confusing cy.env() with Cypress.expose() and accidentally exposing secrets to the application code or developer tools. Saying UI login is faster or more reliable than programmatic methods.
What usually comes next
How would you handle token refresh during a long test suite? What if your app uses OAuth with a third party provider like Auth0 or Google? How do you keep tests independent when sharing a cached session? When is it acceptable to visit external authentication domains?
A concrete example
In a Next.js app with JWT stored in an HttpOnly cookie, a senior candidate would write a cy.session block inside a custom login command. The setup function sends a cy.request to a test-only API route that returns a valid cookie, then cy.setCookie attaches it. The validate function checks that a profile API call returns 200. Every protected-route test calls this command and gets a restored session in under 100 milliseconds instead of driving the UI for five seconds each time.
Interview question
When testing dozens of protected routes in Cypress, which approach best minimizes setup time while maintaining proper test isolation?
- a.Use cy.session to cache validated authentication state and restore it across testsCorrect
- b.Perform a full UI login before each test to guarantee realistic state
- c.Use cy.request in a beforeEach to programmatically authenticate every test
- d.Store a global auth token in localStorage and reuse it across all spec files
Why? this is the answer
cy.session caches the authenticated browser state and restores it instantly across tests while still validating it once, eliminating repeated setup overhead. While cy.request is programmatically correct, running it in every beforeEach still repeats authentication instead of caching it, making it slower than cy.session at scale.
Just read this? Test yourself on what you have been reading.
Read the original → docs.cypress.io
- #cypress
- #authentication
- #e2e-testing
- #test-isolation
- #cypress-session
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles