How to use checkExit method in Cypress

GMaiolo's answer is fundamentally correct.

In case it should be helpful to anyone else, here is a quick function I made (based on GMaiolo's answer) to click on a specific point of a Vuetify v-slider:

// example usage: clickVSlider('#selectID input[role="slider"]', 0.25)

const clickVSlider = (sliderSelector, percentFromLeft) => {
  const sliderWidth = Cypress.$(sliderSelector).width()
  const sliderHeight = Cypress.$(sliderSelector).height()
  const pixelsFromLeft = percentFromLeft * sliderWidth
  const pixelsFromTop = 0.5 * sliderHeight
  cy.get(sliderSelector).click(pixelsFromLeft, pixelsFromTop)
}

Or, perhaps it is preferable to use a more 'composable function' style:

// example usage: cy.get('#selectID input[role="slider"]').then(clickVSlider(0.25))

const clickVSlider = percentFromLeft => subject => {
  const sliderWidth = subject.width()
  const sliderHeight = subject.height()
  const pixelsFromLeft = percentFromLeft * sliderWidth
  const pixelsFromTop = 0.5 * sliderHeight
  cy.wrap(subject).click(pixelsFromLeft, pixelsFromTop)
}

Alternatively, we can create a Cypress custom command, although we want to make sure we don't get too overzealous in the usage of custom commands:

// cypress/support/commands.js
// example usage: cy.get('#selectID input[role="slider"]').clickVSlider(0.25)

Cypress.Commands.add('clickVSlider', {prevSubject: true}, (subject, percentFromLeft) => {
  const sliderWidth = subject.width()
  const sliderHeight = subject.height()
  const pixelsFromLeft = percentFromLeft * sliderWidth
  const pixelsFromTop = 0.5 * sliderHeight
  cy.wrap(subject).click(pixelsFromLeft, pixelsFromTop)
})

I'll just add that if you decide to do if condition by checking the .length property of cy.find command, you need to respect the asynchronous nature of cypress.

Example: Following condition evaluates as false despite appDrawerOpener button exists

    if (cy.find("button[data-cy=appDrawerOpener]").length > 0)    //evaluates as false

But this one evaluates as true because $body variable is already resolved as you're in .then() part of the promise:

    cy.get("body").then($body => {
        if ($body.find("button[data-cy=appDrawerOpener]").length > 0) {   
            //evaluates as true
        }
    });

Read more in Cypress documentation on conditional testing

@jmargolisvt is correct, if you change the .click() operation to a Cypress command, you should get the correct sequence of actions.

Command execution sequence and test loops

Think of it like this - the test code above runs as normal javascript, and each cy.X() command puts a command into the queue. Commands are guaranteed to run sequentially in the queue order, but not synchronously with the test code.

So, the the cy.wait(2000) is not slowing down the for-loop, it's pausing the queue execution.

Waiting for assertions

Note also that commands have built-in waits for their assertions, so you probably don't need either the cy.wait() or the cy.waitUntil() in this scenario. You can control the maximum time for waiting with a timeout option.

Looping

The for loop will work ok if you convert the inner parts to commands, but you can also convert the loop itself to a cy.get().each() command which IMO is much neater.

Testing async content

Lastly, prefer cy.contains('mySelector', 'myContent') command to cy.get('mySelector').contains('myContent') command when waiting for async content.

The reason is cy.get('mySelector').contains('myContent') only waits on the element mySelector, but it's already in the DOM. If the content is asynchronously changing, this command will test the old content (presume empty) immediately and fail the test.

const tbodySelector = '#root > section > section > main > div > div > section.instances > div > div > div > div > div > div > table > tbody';
const buttonSelector = 'td:nth-child(7) > div > button.ant-btn.ant-btn-primary.ant-btn-sm';
const spanSelector = 'td:nth-child(3) > span'

cy.get('.instances__action').each(($el, i) => {

    cy.get(`${tbodySelector} > tr:nth-child(${i+1}) > ${buttonSelector}`)
      .click();

    cy.contains(
      `${tbodySelector} > tr:nth-child(${i+1}) > ${spanSelector}`, 
      'Finished', 
      { timeout: 2000 }  // increase timeout if a longer wait is required
    );  

});

NOTE jQuery's :nth-child(index) selector starts at index 1, but .each(($el, i) => has zero-based indexes, so must use i+1 within these selectors.

This is the mock DOM I used to test with. In a clean Cypress project, put it in folder <project root>/app.

<table>
  <tbody>
    <tr class="instances__action">
      <td>
        <button id="myBtn1"></button>
      </td>
      <td>
        <span id="mySpan1"></span>
      </td>
    </tr>

    <tr class="instances__action">
      <td>
        <button id="myBtn2"></button>
      </td>
      <td>
        <span id="mySpan2"></span>
      </td>
    </tr>
  </tbody>
</table>
<script>
  document.getElementById("myBtn1").addEventListener("click", function() {
    setTimeout(() => {
      document.getElementById("mySpan1").innerHTML = "Finished";
    }, 1000)
  });
  document.getElementById("myBtn2").addEventListener("click", function() {
    setTimeout(() => {
      document.getElementById("mySpan2").innerHTML = "Finished";
    }, 500)
  });
</script>

Note the nesting above is simplified, so I changed the selector contants appropriately.

Testing the above HTML fragment

it('clicks buttons and waits for finished flag', () => {

  cy.visit('app/iterate-table-buttons.html')

  const tbodySelector = 'tbody';
  const buttonSelector = 'td:nth-child(1) > button';
  const spanSelector = 'td:nth-child(2) > span'

  cy.get('.instances__action').each(($el, i) => {

      console.log(`starting #${i}`)

      cy.get(`${tbodySelector} > tr:nth-child(${i+1}) > ${buttonSelector}`)
        .then(() => console.log(`clicking #${i}`))
        .click();

      cy.contains(
        `${tbodySelector} > tr:nth-child(${i+1}) > ${spanSelector}`, 
        'Finished',
        { timeout: 2000 }  // increase timeout if a longer wait is required
      )
      .then(() => console.log(`asserting #${i}`))

  });
})

Cypress log

This is what the Cypress log looks like.
All green, and can see the clicks only happen after the Finished text appears.

1. VISIT app/iterate-table-buttons.html
2. GET .instances__action
3. GET tbody > tr:nth-child(1) > td:nth-child(1) > button
4. CLICK
5. CONTAINS tbody > tr:nth-child(1) > td:nth-child(2) > span, Finished
6. GET tbody > tr:nth-child(2) > td:nth-child(1) > button
7. CLICK
8. CONTAINS tbody > tr:nth-child(2) > td:nth-child(2) > span, Finished

Console log

This is what the console logs look like.

The loop executes to completion before the command queue even begins, but that's ok because the commands are still executing in correct order.

starting #0
starting #1
clicking #0
asserting #0
clicking #1
asserting #1

Accessing new windows via Cypress is intentionally not supported.

However, there are many ways this functionality can be tested in Cypress now. You can split up your tests into separate pieces and still have confidence that your application is covered.

1. Write a test to check that when performing the action in your app, the window.open event is called by using cy.spy() to listen for a window.open event.

cy.visit('http://localhost:3000', {
  onBeforeLoad(win) {
    cy.stub(win, 'open')
  }
})

// Do the action in your app like cy.get('.open-window-btn').click()

cy.window().its('open').should('be.called')

2. In a new test, use cy.visit() to go to the url that would have opened in the new window, fill in the fields and click the buttons like you would in a Cypress test.

cy.visit('http://localhost:3000/new-window')

// Do the actions you want to test in the new window

Fully working test example can be found here.

Ok, a couple of mistakes here.

1. Replace cy.route() by cy.intercept(), since the earlier one was recently deprecated and replace by the later one.
2. Check the correct syntax for using cy.intercept() since it's a bit different from cy.route()
3. I'm assuming that you're trying to bypass some sort of authentication. If all your app requires to consider a user "authenticated" is to have those information on the local storage, you don't even need to perform the POST request, but, if you do, then:
4. Check the usage of cy.intercept() for handling (and stubbing) the request and response objects that are related to your XHR request.
5. For setting the local storage on your Cypress window, you'll need to use the cy.window() command.

In similar situation you can use cy.route() which grab the network request and wait for it. In your case, the route will grab the n/w req and wait for the "Find me" request to get processed completely so that you can proceed with the next filter action.

Steps: Open the chrome console, navigate to network tab, filter for XHR request. Now click on the ''Find me'' button in you page. You can see usually a GET request, for example if the request looks as follows, https://example.com.au/v1/api/listview?page=2 Please copy the url from /v1/api/... and add into the url value of cy.route() as below.

note: On click on Find me button, see its a GET or POST request, usually it will be GET request, check if the url has any encoded value, if it has encoded value you have to use decodeURIComponent() and the pass the url inside as follows >> url:decodeURIComponent('**/v1/api/listview?page=2**'),

beforeEach(()=>{
    cy.server();
    cy.route({
     method: 'GET',
     url:'**/v1/api/listview?page=2**',
     delay: 2000
    }).as('getLoadNewView');
  })

    it('Route waiting for loading the new view for filter action', () => {
      cy.get('[data-cy="search"][data-component="input_box"]').type('Find me{enter}')
      cy.get('[data-name="Find me"]').contains('Find me').click()// Should load a new view 
      cy.wait('@getLoadNewView');
      cy.get('[data-cy = "filter"]').click();
      })

The only way I can see to reliably test the loader is to intercept and delay the response.

See intercept - StaticResponseObject which has a delay option to simulate a slow network, which is the scenario where the user sees the loader.

{
  /**
   * Serve a fixture as the response body.
   */
  fixture?: string
  /**
   * Serve a static string/JSON object as the response body.
   */
  body?: string | object | object[]
  /**
   * HTTP headers to accompany the response.
   * @default {}
   */
  headers?: { [key: string]: string }
  /**
   * The HTTP status code to send.
   * @default 200
   */
  statusCode?: number
  /**
   * If 'forceNetworkError' is truthy, Cypress will destroy the browser connection
   * and send no response. Useful for simulating a server that is not reachable.
   * Must not be set in combination with other options.
   */
  forceNetworkError?: boolean
  /**
   * Milliseconds to delay before the response is sent.
   */
  delay?: number
  /**
   * Kilobits per second to send 'body'.
   */
  throttleKbps?: number
}

You can do it more easily by combining selectors

cy.get('tr img[src="/static/images/icon_profile.png"]')
  .first()
  .parent('a')  // click the link not the img
  .click()

To confirm you have the right index when using .eq(50) run

cy.get('tr img[src="/static/images/icon_profile.png"]')
  .first()
  .parent('tr')
  .invoke('index')  // which row is it?
  .log()

to run only one file

cypress run --spec path/to/file.spec.js

or using glob patterns:

cypress run --spec 'path/to/files/*.spec.js'

Note: you need to wrap your glob patterns in single quotes to avoid shell expansion!

to run only one test in a file

You can use a .only as described in the Cypress docs

it.only('only run this one', () => {
  // similarly use it.skip(...) to skip a test
})

it('not this one', () => {
})

Also, you can do the same with describe and context blocks

edit:

there's also a nice VSCode extension to make adding/removing .only's easier with keyboard shortcuts. It's called Test Utils (install with ext install chrisbreiding.test-utils). It works with js, coffee, and typescript: