VocalHyre
Sign up

Cypress · Browser testing end to end

How do you write your first Cypress test?

Easyfirst testdescribeitUpdated Oct 2026
Quiz this track

Short answer

Create a .cy.ts spec, use describe and it, visit a page, interact through Cypress commands, and assert on a user-visible result. Cypress queues the commands and retries assertions automatically.

A Cypress test is a function passed to it inside a describe block. Inside it, commands are not promises and you do not await them. Each command is added to a queue and Cypress runs the queue in order, retrying the last command's assertions until they pass or time out.

ts
describe("todo app", () => {
  it("adds a todo", () => {
    cy.visit("/");
    cy.get("[data-cy=new-todo]").type("Ship the release{enter}");
    cy.get("[data-cy=todo-list]")
      .should("contain", "Ship the release");
  });
});
The test visits, types, and asserts. There is no manual wait between typing and asserting.

What happens on failure

  • Cypress stops the spec by default at the first failing test
  • The runner shows the command that failed and a DOM snapshot
  • A screenshot is captured on failure in run mode
  • The error includes the selector and the assertion that did not pass

Keep the first test focused on one behaviour. A test that visits, logs in, creates a record and checks three pages is hard to diagnose. Split independent behaviours into separate it blocks so failures point to one thing.

Do not return the Cypress chain like a promise or add await. Cypress commands are queued; returning a value from it is unnecessary and awaiting a chain is not how the runner works.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1Why should you not await a Cypress command?
  2. 2What happens after the first failing test in a spec?
  3. 3How do you test an enter key submission?
  4. 4Where does the screenshot go on failure?

Say it in the interview

I create a spec under cypress/e2e and use describe and it. Inside it I call cy.visit, interact with selectors and assert on visible text or state. I do not await commands because Cypress queues them itself. I keep each test focused on one behaviour so the runner points directly at the broken step when something fails.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

EasyHow do you set up a Cypress project?MediumHow does the Cypress command chain work?MediumHow do assertions work in Cypress?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Cypress mock interview and get scored feedback on depth, clarity and confidence.

Start a free Cypress interviewBrowse all questions