{
  "doc": {
    "id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
    "title": "End-to-End Testing: Your First Test with Cypress",
    "description": "Dive into Cypress end-to-end testing with a guide on writing your first test. Learn step-by-step, best practices, and tips for efficient test creation",
    "section": "app",
    "source_path": "/llm/markdown/app/end-to-end-testing/writing-your-first-end-to-end-test.md",
    "version": "e6988a974973e9090ce70406c38cb2b9e0eac9fa",
    "updated_at": "2026-05-15T15:50:22.536Z",
    "headings": [
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#your-first-test",
        "text": "Your First Test",
        "level": 1
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#what-youll-learn",
        "text": "What you'll learn",
        "level": 5
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#add-a-test-file",
        "text": "Add a test file",
        "level": 2
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#write-your-first-test",
        "text": "Write your first test",
        "level": 2
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#write-a-real-test",
        "text": "Write a real test",
        "level": 2
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-1-visit-a-page",
        "text": "Step 1: Visit a page",
        "level": 3
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-2-query-for-an-element",
        "text": "Step 2: Query for an element",
        "level": 3
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-3-click-an-element",
        "text": "Step 3: Click an element",
        "level": 3
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-4-make-an-assertion",
        "text": "Step 4: Make an assertion",
        "level": 3
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#adding-more-commands-and-assertions",
        "text": "Adding more commands and assertions",
        "level": 4
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#record-tests-with-cypress-studio",
        "text": "Record Tests with Cypress Studio",
        "level": 2
      },
      {
        "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#next-steps",
        "text": "Next steps",
        "level": 2
      }
    ]
  },
  "chunks": [
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#what-youll-learn",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "What you'll learn",
      "heading_level": 5,
      "content_markdown": "##### What you'll learn\n\n*   How to write your first end-to-end test in Cypress using an example app\n*   How to use Cypress commands to interact with elements on a page\n*   How to make assertions about the state of the application\n",
      "section": "app",
      "anchors": [
        "what-youll-learn"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 56
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#add-a-test-file",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Add a test file",
      "heading_level": 2,
      "content_markdown": "## Add a test file\n\nAssuming you've successfully [installed Cypress](/llm/markdown/app/get-started/install-cypress.md) and [opened Cypress](/llm/markdown/app/get-started/open-the-app.md), now it's time to add your first test. We're going to do this with the **Create new empty spec** button.\n\nOn clicking it, you should see a dialog where you can enter the name of your new spec. Just accept the default name for now.\n\nThe newly-generated spec is displayed in a confirmation dialog. Just go ahead and close it with the ✕ button.\n\nOnce we've created that file, you should see it immediately displayed in the list of end-to-end specs. Cypress monitors your spec files for any changes and automatically displays any changes.\n\nEven though we haven't written any code yet - that's okay - let's click on your new spec and watch Cypress launch it. Cypress will visit `https://example.cypress.io` and the test passes.\n",
      "section": "app",
      "anchors": [
        "add-a-test-file"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 184
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#write-your-first-test",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Write your first test",
      "heading_level": 2,
      "content_markdown": "## Write your first test\n\nNow it's time to write your first test. We're going to:\n\n1.  Write your first passing test.\n2.  Update it so it fails.\n3.  Watch Cypress reload in real time.\n\nOpen up your favorite IDE and replace the contents of your spec with the code below.\n\n```\ndescribe('My First Test', () => {  it('Does not do much!', () => {    expect(true).to.equal(true)  })})\n```\n\nOnce you save this change you should see the browser reload.\n\nAlthough it doesn't do anything useful, this is our first passing test! ✅\n\nOver in the [Command Log](/llm/markdown/app/core-concepts/open-mode.md#Command-Log) you'll see Cypress display the suite, the test and your first assertion (which should be passing in green).\n\nNotice Cypress displays a message about this being the default page [on the righthand side](/llm/markdown/app/core-concepts/open-mode.md#Application-Under-Test). Cypress assumes you'll want to go out and [visit](/llm/markdown/api/commands/visit.md) a URL on the internet - but it can also work just fine without that.\n\nNow let's write our first failing test.\n\n```\ndescribe('My First Test', () => {  it('Does not do much!', () => {    expect(true).to.equal(false)  })})\n```\n\nOnce you save again, you'll see Cypress display the failing test in red since `true` does not equal `false`.\n\nCypress displays a detailed error view that includes the stack trace and the exact code frame where the assertion failed. This helps you quickly identify and fix the issue.\n\nIf you don't see the code frame or stack trace, you may need to [enable sourcemaps](/llm/markdown/app/guides/debugging.md#Source-maps) for better debugging information.\n\nYou can click on the blue file link to open the file where the error occurred in [your preferred file opener](/llm/markdown/app/tooling/IDE-integration.md#File-Opener-Preference). To read more about the error's display, read about [Debugging Errors](/llm/markdown/app/guides/debugging.md#Errors).\n\n[Cypress](/llm/markdown/app/core-concepts/open-mode.md) gives you a visual structure of suites, tests, and assertions. Soon you'll also see commands, page events, network requests, and more.\n\n**What are _describe_, _it_, and _expect_ ?**\n\nAll of these functions come from [Bundled Libraries](/llm/markdown/app/references/bundled-libraries.md) that Cypress bakes in.\n\n*   `describe` and `it` come from [Mocha](https://mochajs.org)\n*   `expect` comes from [Chai](http://www.chaijs.com)\n\nCypress builds on these popular tools and frameworks that you _hopefully_ already have some familiarity and knowledge of. If not, that's okay too.\n",
      "section": "app",
      "anchors": [
        "write-your-first-test"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 472
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#write-a-real-test",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Write a real test",
      "heading_level": 2,
      "content_markdown": "## Write a _real_ test\n\n**A solid test generally covers 3 phases:**\n\n1.  Set up the application state.\n2.  Take an action.\n3.  Make an assertion about the resulting application state.\n\nYou might also see this phrased as \"Given, When, Then\", or \"Arrange, Act, Assert\". But the idea is: First you put the application into a specific state, then you take some action in the application that causes it to change, and finally you check the resulting application state.\n\nToday, we'll take a narrow view of these steps and map them cleanly to Cypress commands:\n\n1.  Visit a web page.\n2.  Query for an element.\n3.  Interact with that element.\n4.  Assert about the content on the page.\n\n### Step 1: Visit a page\n\nFirst, let's visit a web page. We will visit our [Kitchen Sink](https://github.com/cypress-io/cypress-example-kitchensink) application in this example so that you can try Cypress out without needing to worry about finding a page to test.\n\nWe can pass the URL we want to visit to [`cy.visit()`](/llm/markdown/api/commands/visit.md). Let's replace our previous test with the one below that actually visits a page:\n\n```\ndescribe('My First Test', () => {  it('Visits the Kitchen Sink', () => {    cy.visit('https://example.cypress.io')  })})\n```\n\nSave the file and switch back over to the Cypress Test Runner. You might notice a few things:\n\n1.  The [Command Log](/llm/markdown/app/core-concepts/open-mode.md#Command-Log) now shows the new `VISIT` action.\n2.  The Kitchen Sink application has been loaded into the [App](/llm/markdown/app/core-concepts/open-mode.md).\n3.  The test is green, even though we made no assertions.\n4.  The `VISIT` displays a **blue pending state** until the page finishes loading.\n\nHad this request come back with a non `2xx` status code such as `404` or `500`, or if there was a JavaScript error in the application's code, the test would have failed.\n\n### Step 2: Query for an element\n\nNow that we've got a page loaded, we need to take some action on it. Why don't we click a link on the page? Sounds easy enough, let's go look for one we like... how about `type`?\n\nTo find this element by its contents, we'll use [cy.contains()](/llm/markdown/api/commands/contains.md).\n\nLet's add it to our test and see what happens:\n\n```\ndescribe('My First Test', () => {  it('finds the content \"type\"', () => {    cy.visit('https://example.cypress.io')    cy.contains('type')  })})\n```\n\nOur test should now display `CONTAINS` in the [Command Log](/llm/markdown/app/core-concepts/open-mode.md#Command-Log) and still be green.\n\nEven without adding an assertion, we know that everything is okay! This is because many of Cypress' commands are built to fail if they don't find what they're expecting to find. This is known as an [Implicit Assertion](/llm/markdown/app/core-concepts/introduction-to-cypress.md#Implicit-Assertions).\n\nTo verify this, replace `type` with something not on the page, like `hype`. You'll notice the test goes red, but only after about 4 seconds!\n\nCan you see what Cypress is doing under the hood? It's automatically waiting and retrying because it expects the content to **eventually** be found in the DOM. It doesn't immediately fail!\n\n**Error Messages**\n\nCypress provides detailed, human-readable error messages that explain exactly what went wrong. In this case, Cypress **timed out retrying** to find the content `hype` within the entire page. These descriptive error messages help you quickly understand and fix issues in your tests. For more information about how Cypress displays errors, see [Debugging Errors](/llm/markdown/app/guides/debugging.md#Errors).\n\nBefore we add another command - let's get this test back to passing. Replace `hype` with `type`.\n\n### Step 3: Click an element\n\nOk, now we want to click on the link we found. How do we do that? Add a [.click()](/llm/markdown/api/commands/click.md) command to the end of the previous command, like so:\n\n```\ndescribe('My First Test', () => {  it('clicks the link \"type\"', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()  })})\n```\n\nYou can almost read it like a little story! Cypress calls this \"chaining\" and we chain together commands to build tests that really express what the app does in a declarative way.\n\nAlso note that the [App](/llm/markdown/app/core-concepts/open-mode.md) has updated further after the click, following the link and showing the destination page:\n\nNow we can assert something about this new page!\n\n✨ IntelliSense is available in your Cypress spec files by adding a special triple slash comment line. Read about [Intelligent Code Completion](/llm/markdown/app/tooling/IDE-integration.md#Triple-slash-directives).\n\n### Step 4: Make an assertion\n\nLet's make an assertion about something on the new page we clicked into. Perhaps we'd like to make sure the new URL is the expected URL. We can do that by looking up the URL and chaining an assertion to it with [.should()](/llm/markdown/api/commands/should.md).\n\nHere's what that looks like:\n\n```\ndescribe('My First Test', () => {  it('clicking \"type\" navigates to a new url', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()    // Should be on a new URL which    // includes '/commands/actions'    cy.url().should('include', '/commands/actions')  })})\n```\n\n#### Adding more commands and assertions\n\nWe are not limited to a single interaction and assertion in a given test. In fact, many interactions in an application may require multiple steps and are likely to change your application state in more than one way.\n\nWe can continue the interactions and assertions in this test by adding another chain to interact with and verify the behavior of elements on this new page.\n\nWe can use [cy.get()](/llm/markdown/api/commands/get.md) to select an element based on its class. Then we can use the [.type()](/llm/markdown/api/commands/type.md) command to enter text into the selected input. Finally, we can verify that the value of the input reflects the text that was typed with another [.should()](/llm/markdown/api/commands/should.md).\n\nIn general, the structure of your test should flow query -> query -> command or assertion(s). It's best practice not to chain anything after an action command; for more details on why this is, see our guide on [retry-ability](/llm/markdown/app/core-concepts/retry-ability.md).\n\n```\ndescribe('My First Test', () => {  it('Gets, types and asserts', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()    // Should be on a new URL which    // includes '/commands/actions'    cy.url().should('include', '/commands/actions')    // Get an input, type into it    cy.get('.action-email').type('fake@email.com')    //  Verify that the value has been updated    cy.get('.action-email').should('have.value', 'fake@email.com')  })})\n```\n\nAnd there you have it: a short test in Cypress that visits a page, finds and clicks a link, verifies the URL and then verifies the behavior of an element on the new page. If we read it out loud, it might sound like:\n\n1.  _Visit: `https://example.cypress.io`_\n2.  _Find the element with content: `type`_\n3.  _Click on it_\n4.  _Get the URL_\n5.  _Assert it includes: `/commands/actions`_\n6.  _Get the input with the `action-email` class_\n7.  _Type `fake@email.com` into the input_\n8.  _Assert the input reflects the new value_\n\nOr in the _Given_, _When_, _Then_ syntax:\n\n1.  _**Given** a user visits `https://example.cypress.io`_\n2.  _**When** they click the link labeled `type`_\n3.  _And they type \"[fake@email.com](mailto:fake@email.com)\" into the input that has a class of `action-email` input_\n4.  _**Then** the URL should include `/commands/actions`_\n5.  _And the `[class=\"action-email\"]` input has \"[fake@email.com](mailto:fake@email.com)\" as its value_\n\nAnd hey, this is a very clean test! We didn't have to say anything about _how_ things work, just that we'd like to verify a particular series of events and outcomes.\n\n**Page Transitions**\n\nWorth noting is that this test transitioned across two different pages.\n\n1.  The initial [cy.visit()](/llm/markdown/api/commands/visit.md)\n2.  The [.click()](/llm/markdown/api/commands/click.md) to a new page\n\nCypress automatically detects things like a `page transition event` and will automatically **halt** running commands until the next page has **finished** loading.\n\nHad the **next page** not finished its loading phase, Cypress would have ended the test and presented an error.\n\nUnder the hood - this means you don't have to worry about commands accidentally running against a stale page, nor do you have to worry about running commands against a partially loaded page.\n\nWe mentioned previously that Cypress waited **4 seconds** before timing out finding a DOM element - but in this case, when Cypress detects a `page transition event` it automatically increases the timeout to **60 seconds** for the single `PAGE LOAD` event.\n\nIn other words, based on the commands and the events happening, Cypress automatically alters its expected timeouts to match web application behavior.\n\nThese various timeouts are defined in the [Configuration](/llm/markdown/app/references/configuration.md#Timeouts) document.\n",
      "section": "app",
      "anchors": [
        "write-a-real-test"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 1768
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-1-visit-a-page",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Step 1: Visit a page",
      "heading_level": 3,
      "content_markdown": "### Step 1: Visit a page\n\nFirst, let's visit a web page. We will visit our [Kitchen Sink](https://github.com/cypress-io/cypress-example-kitchensink) application in this example so that you can try Cypress out without needing to worry about finding a page to test.\n\nWe can pass the URL we want to visit to [`cy.visit()`](/llm/markdown/api/commands/visit.md). Let's replace our previous test with the one below that actually visits a page:\n\n```\ndescribe('My First Test', () => {  it('Visits the Kitchen Sink', () => {    cy.visit('https://example.cypress.io')  })})\n```\n\nSave the file and switch back over to the Cypress Test Runner. You might notice a few things:\n\n1.  The [Command Log](/llm/markdown/app/core-concepts/open-mode.md#Command-Log) now shows the new `VISIT` action.\n2.  The Kitchen Sink application has been loaded into the [App](/llm/markdown/app/core-concepts/open-mode.md).\n3.  The test is green, even though we made no assertions.\n4.  The `VISIT` displays a **blue pending state** until the page finishes loading.\n\nHad this request come back with a non `2xx` status code such as `404` or `500`, or if there was a JavaScript error in the application's code, the test would have failed.\n",
      "section": "app",
      "anchors": [
        "step-1-visit-a-page"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 235
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-2-query-for-an-element",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Step 2: Query for an element",
      "heading_level": 3,
      "content_markdown": "### Step 2: Query for an element\n\nNow that we've got a page loaded, we need to take some action on it. Why don't we click a link on the page? Sounds easy enough, let's go look for one we like... how about `type`?\n\nTo find this element by its contents, we'll use [cy.contains()](/llm/markdown/api/commands/contains.md).\n\nLet's add it to our test and see what happens:\n\n```\ndescribe('My First Test', () => {  it('finds the content \"type\"', () => {    cy.visit('https://example.cypress.io')    cy.contains('type')  })})\n```\n\nOur test should now display `CONTAINS` in the [Command Log](/llm/markdown/app/core-concepts/open-mode.md#Command-Log) and still be green.\n\nEven without adding an assertion, we know that everything is okay! This is because many of Cypress' commands are built to fail if they don't find what they're expecting to find. This is known as an [Implicit Assertion](/llm/markdown/app/core-concepts/introduction-to-cypress.md#Implicit-Assertions).\n\nTo verify this, replace `type` with something not on the page, like `hype`. You'll notice the test goes red, but only after about 4 seconds!\n\nCan you see what Cypress is doing under the hood? It's automatically waiting and retrying because it expects the content to **eventually** be found in the DOM. It doesn't immediately fail!\n\n**Error Messages**\n\nCypress provides detailed, human-readable error messages that explain exactly what went wrong. In this case, Cypress **timed out retrying** to find the content `hype` within the entire page. These descriptive error messages help you quickly understand and fix issues in your tests. For more information about how Cypress displays errors, see [Debugging Errors](/llm/markdown/app/guides/debugging.md#Errors).\n\nBefore we add another command - let's get this test back to passing. Replace `hype` with `type`.\n",
      "section": "app",
      "anchors": [
        "step-2-query-for-an-element"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 349
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-3-click-an-element",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Step 3: Click an element",
      "heading_level": 3,
      "content_markdown": "### Step 3: Click an element\n\nOk, now we want to click on the link we found. How do we do that? Add a [.click()](/llm/markdown/api/commands/click.md) command to the end of the previous command, like so:\n\n```\ndescribe('My First Test', () => {  it('clicks the link \"type\"', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()  })})\n```\n\nYou can almost read it like a little story! Cypress calls this \"chaining\" and we chain together commands to build tests that really express what the app does in a declarative way.\n\nAlso note that the [App](/llm/markdown/app/core-concepts/open-mode.md) has updated further after the click, following the link and showing the destination page:\n\nNow we can assert something about this new page!\n\n✨ IntelliSense is available in your Cypress spec files by adding a special triple slash comment line. Read about [Intelligent Code Completion](/llm/markdown/app/tooling/IDE-integration.md#Triple-slash-directives).\n",
      "section": "app",
      "anchors": [
        "step-3-click-an-element"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 180
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#step-4-make-an-assertion",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Step 4: Make an assertion",
      "heading_level": 3,
      "content_markdown": "### Step 4: Make an assertion\n\nLet's make an assertion about something on the new page we clicked into. Perhaps we'd like to make sure the new URL is the expected URL. We can do that by looking up the URL and chaining an assertion to it with [.should()](/llm/markdown/api/commands/should.md).\n\nHere's what that looks like:\n\n```\ndescribe('My First Test', () => {  it('clicking \"type\" navigates to a new url', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()    // Should be on a new URL which    // includes '/commands/actions'    cy.url().should('include', '/commands/actions')  })})\n```\n\n#### Adding more commands and assertions\n\nWe are not limited to a single interaction and assertion in a given test. In fact, many interactions in an application may require multiple steps and are likely to change your application state in more than one way.\n\nWe can continue the interactions and assertions in this test by adding another chain to interact with and verify the behavior of elements on this new page.\n\nWe can use [cy.get()](/llm/markdown/api/commands/get.md) to select an element based on its class. Then we can use the [.type()](/llm/markdown/api/commands/type.md) command to enter text into the selected input. Finally, we can verify that the value of the input reflects the text that was typed with another [.should()](/llm/markdown/api/commands/should.md).\n\nIn general, the structure of your test should flow query -> query -> command or assertion(s). It's best practice not to chain anything after an action command; for more details on why this is, see our guide on [retry-ability](/llm/markdown/app/core-concepts/retry-ability.md).\n\n```\ndescribe('My First Test', () => {  it('Gets, types and asserts', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()    // Should be on a new URL which    // includes '/commands/actions'    cy.url().should('include', '/commands/actions')    // Get an input, type into it    cy.get('.action-email').type('fake@email.com')    //  Verify that the value has been updated    cy.get('.action-email').should('have.value', 'fake@email.com')  })})\n```\n\nAnd there you have it: a short test in Cypress that visits a page, finds and clicks a link, verifies the URL and then verifies the behavior of an element on the new page. If we read it out loud, it might sound like:\n\n1.  _Visit: `https://example.cypress.io`_\n2.  _Find the element with content: `type`_\n3.  _Click on it_\n4.  _Get the URL_\n5.  _Assert it includes: `/commands/actions`_\n6.  _Get the input with the `action-email` class_\n7.  _Type `fake@email.com` into the input_\n8.  _Assert the input reflects the new value_\n\nOr in the _Given_, _When_, _Then_ syntax:\n\n1.  _**Given** a user visits `https://example.cypress.io`_\n2.  _**When** they click the link labeled `type`_\n3.  _And they type \"[fake@email.com](mailto:fake@email.com)\" into the input that has a class of `action-email` input_\n4.  _**Then** the URL should include `/commands/actions`_\n5.  _And the `[class=\"action-email\"]` input has \"[fake@email.com](mailto:fake@email.com)\" as its value_\n\nAnd hey, this is a very clean test! We didn't have to say anything about _how_ things work, just that we'd like to verify a particular series of events and outcomes.\n\n**Page Transitions**\n\nWorth noting is that this test transitioned across two different pages.\n\n1.  The initial [cy.visit()](/llm/markdown/api/commands/visit.md)\n2.  The [.click()](/llm/markdown/api/commands/click.md) to a new page\n\nCypress automatically detects things like a `page transition event` and will automatically **halt** running commands until the next page has **finished** loading.\n\nHad the **next page** not finished its loading phase, Cypress would have ended the test and presented an error.\n\nUnder the hood - this means you don't have to worry about commands accidentally running against a stale page, nor do you have to worry about running commands against a partially loaded page.\n\nWe mentioned previously that Cypress waited **4 seconds** before timing out finding a DOM element - but in this case, when Cypress detects a `page transition event` it automatically increases the timeout to **60 seconds** for the single `PAGE LOAD` event.\n\nIn other words, based on the commands and the events happening, Cypress automatically alters its expected timeouts to match web application behavior.\n\nThese various timeouts are defined in the [Configuration](/llm/markdown/app/references/configuration.md#Timeouts) document.\n",
      "section": "app",
      "anchors": [
        "step-4-make-an-assertion"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 847
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#adding-more-commands-and-assertions",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Adding more commands and assertions",
      "heading_level": 4,
      "content_markdown": "#### Adding more commands and assertions\n\nWe are not limited to a single interaction and assertion in a given test. In fact, many interactions in an application may require multiple steps and are likely to change your application state in more than one way.\n\nWe can continue the interactions and assertions in this test by adding another chain to interact with and verify the behavior of elements on this new page.\n\nWe can use [cy.get()](/llm/markdown/api/commands/get.md) to select an element based on its class. Then we can use the [.type()](/llm/markdown/api/commands/type.md) command to enter text into the selected input. Finally, we can verify that the value of the input reflects the text that was typed with another [.should()](/llm/markdown/api/commands/should.md).\n\nIn general, the structure of your test should flow query -> query -> command or assertion(s). It's best practice not to chain anything after an action command; for more details on why this is, see our guide on [retry-ability](/llm/markdown/app/core-concepts/retry-ability.md).\n\n```\ndescribe('My First Test', () => {  it('Gets, types and asserts', () => {    cy.visit('https://example.cypress.io')    cy.contains('type').click()    // Should be on a new URL which    // includes '/commands/actions'    cy.url().should('include', '/commands/actions')    // Get an input, type into it    cy.get('.action-email').type('fake@email.com')    //  Verify that the value has been updated    cy.get('.action-email').should('have.value', 'fake@email.com')  })})\n```\n\nAnd there you have it: a short test in Cypress that visits a page, finds and clicks a link, verifies the URL and then verifies the behavior of an element on the new page. If we read it out loud, it might sound like:\n\n1.  _Visit: `https://example.cypress.io`_\n2.  _Find the element with content: `type`_\n3.  _Click on it_\n4.  _Get the URL_\n5.  _Assert it includes: `/commands/actions`_\n6.  _Get the input with the `action-email` class_\n7.  _Type `fake@email.com` into the input_\n8.  _Assert the input reflects the new value_\n\nOr in the _Given_, _When_, _Then_ syntax:\n\n1.  _**Given** a user visits `https://example.cypress.io`_\n2.  _**When** they click the link labeled `type`_\n3.  _And they type \"[fake@email.com](mailto:fake@email.com)\" into the input that has a class of `action-email` input_\n4.  _**Then** the URL should include `/commands/actions`_\n5.  _And the `[class=\"action-email\"]` input has \"[fake@email.com](mailto:fake@email.com)\" as its value_\n\nAnd hey, this is a very clean test! We didn't have to say anything about _how_ things work, just that we'd like to verify a particular series of events and outcomes.\n\n**Page Transitions**\n\nWorth noting is that this test transitioned across two different pages.\n\n1.  The initial [cy.visit()](/llm/markdown/api/commands/visit.md)\n2.  The [.click()](/llm/markdown/api/commands/click.md) to a new page\n\nCypress automatically detects things like a `page transition event` and will automatically **halt** running commands until the next page has **finished** loading.\n\nHad the **next page** not finished its loading phase, Cypress would have ended the test and presented an error.\n\nUnder the hood - this means you don't have to worry about commands accidentally running against a stale page, nor do you have to worry about running commands against a partially loaded page.\n\nWe mentioned previously that Cypress waited **4 seconds** before timing out finding a DOM element - but in this case, when Cypress detects a `page transition event` it automatically increases the timeout to **60 seconds** for the single `PAGE LOAD` event.\n\nIn other words, based on the commands and the events happening, Cypress automatically alters its expected timeouts to match web application behavior.\n\nThese various timeouts are defined in the [Configuration](/llm/markdown/app/references/configuration.md#Timeouts) document.\n",
      "section": "app",
      "anchors": [
        "adding-more-commands-and-assertions"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 729
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#record-tests-with-cypress-studio",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Record Tests with Cypress Studio",
      "heading_level": 2,
      "content_markdown": "## Record Tests with Cypress Studio\n\nIf you want a minimal code approach to creating tests, you can use [Cypress Studio](/llm/markdown/app/guides/cypress-studio.md) to record your browser interactions and generate tests. With a [Cypress Cloud](/llm/markdown/cloud/get-started/introduction.md) account, you also get **Studio AI**—assertion recommendations as you record. Visit our [guide](/llm/markdown/app/guides/cypress-studio.md) for more information.\n",
      "section": "app",
      "anchors": [
        "record-tests-with-cypress-studio"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 65
    },
    {
      "id": "app/end-to-end-testing/writing-your-first-end-to-end-test#next-steps",
      "doc_id": "app/end-to-end-testing/writing-your-first-end-to-end-test",
      "heading": "Next steps",
      "heading_level": 2,
      "content_markdown": "## Next steps\n\n*   [Test your own app](/llm/markdown/app/end-to-end-testing/testing-your-app.md) — apply what you learned here to a real project.\n*   [Introduction to Cypress](/llm/markdown/app/core-concepts/introduction-to-cypress.md) — understand how Cypress really works under the hood.\n*   [Best Practices](/llm/markdown/app/core-concepts/best-practices.md) — learn selector strategies, state management, and patterns for maintainable tests.\n*   [Cypress AI Skills](/llm/markdown/app/tooling/ai-skills.md) — use your AI coding tool to write, fix, and review Cypress tests with best practices built in.\n",
      "section": "app",
      "anchors": [
        "next-steps"
      ],
      "path": "/llm/json/chunked/app/end-to-end-testing/writing-your-first-end-to-end-test.json",
      "token_estimate": 89
    }
  ]
}