How to use getMsFromDuration method in Cypress

This looks like the culprit cy.get('table#return-request-list').find('tr').eq(1). You get the row you want to delete, you delete it, then you wrapping the delete row element even though it does not exist. So it will return undefined. You should instead get all rows initially.

function deleteTheNewestRequest(){
    // get all rows in table
    cy.get('table#return-request-list').find('tr').then( rows => {
        // get last row and store rowId
        cy.wrap(rows).last().find('td').first().invoke('text').as('deletedRowId')
        cy.wrap(rows).last().find('a[title="Delete"]').click()
        cy.get('button.btn-delete-return-request').click()
        // check new last row does not have same rowId
        cy.wrap(rows).last().find('td').first().should('not.have.text', this.rowId)
    })
}

Cypress requires the ability to run its GUI. Depending on your Windows version, you likely need some additional configuration in order to run GUI applications in WSL:

• For all Windows releases, make sure you install the required dependencies:

  apt-get install libgtk2.0-0 libgtk-3-0 libgbm-dev libnotify-dev libgconf-2-4 libnss3 libxss1 libasound2 libxtst6 xauth xvfb
  

  This may have been done for you depending on how you installed Cypress. I used the npm directions in the Cypress doc.

• Windows 11 includes the WSLg feature by default, which allows you to run GUI applications directly on Windows. If you upgraded from Windows 10 to Windows 11, run wsl --update to make sure you have the latest WSL version with WSLg.

  Also make sure, if you've attempted to run an X server on an older release (like in the next suggestion), that you remove any manual configuration of DISPLAY in your startup files (e.g. ~/.bashrc, etc.).

• For Windows 10, you will need to do some additional configuration. There are really two ways to do this, but it's a better topic for Super User (since it isn't directly related to programming), so I'm going to point you to this Super User question for some details. Either answer there is fine. While I'm partial to my solution, most people opt for running a third-party X server as in harrymc's answer there.

Just to make sure there weren't any "hidden tricks" needed to get Cypress running, I can confirm that I was able to successfully ./node_modules/.bin/cypress open using the Cypress instructions and my xrdp technique from the Super User answer.

Finally, I find the way to do it. Although Cypress doesn't provide such a feature, but since Cypress uses Chai, we can just define Chai methods.

Note: it's not possible to define have.text.trimmed, since assertion method text is a Chai method. rather than a chainable method, there is no way to provide a trimmed after it.

But there are still two options:

1. Define a Chai method textTrimmed. It allows us using .should('have.textTrimmed', 'sometext'), which is preferred since we can define a custom assertion message and no tricky hacking on jQuery instances.

2. Define a Chai chainable method trimmed. It allows using .should('have.trimmed.text', 'sometext'), which seems to work, but the assertion is determined by the Chai method text, which may be confusion. It is not recommended.

have.textTrimmed

This is in TypeScript:

chai.Assertion.addMethod('textTrimmed', function (expectedString: string) {
  const $element = this._obj;

  new chai.Assertion($element).to.be.exist;

  const actual = $element.text().trim();
  const expected = expectedString.trim();
  this.assert(
    actual === expected
    , ' Expected #{this} to have text #{exp} after trimmed, but the text was #{act} after trimmed'
    , 'expected #{this} not to have text #{exp} after trimmed'
    , expected
    , actual
  );
});

Put the code in cypress/support/index.js file to make sure running it before tests.

You may want to see the complete demo here: https://github.com/freewind-demos/typescript-cypress-add-custom-assertion-method-textTrimmed-demo/blob/master/cypress/support/textTrimmed.ts

File have.trimmed.text

chai.use((chai, utils) => {

  chai.Assertion.addChainableMethod("trimmed", () => {
  }, function () {
    const obj = utils.flag(this, 'object')

    const oldText = obj.text.bind(obj);
    obj.text = () => {
      return oldText().trim()
    }
  });
})

As I said, it's not recommended because of the tricky hack and unclear assertion message.

You can also see the complete demo here: https://github.com/freewind-demos/typescript-cypress-custom-operator-have-trimmed-text-demo/blob/master/cypress/support/index.ts

A couple of things to note,

• there are two window objects in a Cypress test, the one the test runs in and the one the app runs in. Your call to console.error('questo e errore') is to the first, but your spy is on the second.

• test code runs faster than Cypress commands, so console.error('questo e errore') is running before cy.visit() gets done.

These example all work,

Spying on runner window console

it('should spy on RUNNER window.error', () => {
  cy.spy(window.console, 'error').as('spyWinConsoleError');
  console.error('questo e errore')
  cy.get('@spyWinConsoleError').should('be.calledOnce');
});

Spying on app window console

it('should spy on APP window.error', () => {
  const win = cy.state('window')
  cy.spy(win.console, 'error').as('spyWinConsoleError');
  
  win.console.error('questo e errore')
  cy.get('@spyWinConsoleError').should('be.calledOnce');
});

Catching an actual app error

it('should spy window.error', () => {
  cy.visit('../app/spy-on-win-error.html', {
    onBeforeLoad(win) {
      cy.spy(win.console, 'error').as('spyWinConsoleError');
    },
  })
  cy.get('@spyWinConsoleError').should('be.calledWith', 'from app');
});

<body>
  <script>
    setTimeout(() => {
      console.error('from app')
    }, 1000)
  </script>
</body>

Waiting for spiegel.de to load

it('should spy window.error', () => {

  cy.visit('https://www.spiegel.de/', {
    onBeforeLoad(win) {
      cy.spy(win.console, 'error').as('spyWinConsoleError');
      win.console.error("questo è l'errore due");      // call here after spy is set
    },
  })

  cy.get('@spyWinConsoleError')
    .should('be.calledOnce');
});

I would say you are on the right track, but .contains(/^Tier2_Forest/) fails because the text is not at the beginning of the string, there is white space preceding it.

Just try .contains(/Tier2_Forest/)

or more precisely .contains(/\s*Tier2_Forest/)

where \s* matches any whitespace character (equal to [\r\n\t\f\v ])

Check it out in https://regex101.com

There a number of ways to approach flaky tests. You can try these and check what suits best for your use case:

1.Test Retires easy and effective, just retry the execution automatically it something fails. Can be applied, globally using cypress.json or to a describe block or to a it block as well.

For it block:

  // `it` test block with custom configuration
  it('allows user to login', {
    retries: {
      runMode: 2,
      openMode: 2
    }
  }, () => {
    // ...
  })

For describe block:

// Customizing retry attempts for a suite of tests
describe('User bank accounts', {
  retries: {
    runMode: 2,
    openMode: 2,
  }
}, () => {
  // The per-suite configuration is applied to each test
  // If a test fails, it will be retried
  it('allows a user to view their transactions', () => {
    // ...
  }

  it('allows a user to edit their transactions', () => {
    // ...
  }
})

2.Adding .visible and click() before writing into the name field

it("Can fill out form and submit", () => {
    cy.get("#modal-button").click()
    cy.get("#modal-form").should("exist")
    cy.get("#form-name").should('be.visible') //making sure the name field is visible
    cy.get("#form-name").click() //clicking on the name field
    cy.get("#form-name").type("Mike Johnson")
    cy.get("#form-age").type("33")
    cy.get("#form-email").type("mj09@yahoo.com")
    cy.get("#submit-button").click()
})

3.Use timeouts instead of waits

cy.get("#form-name", {timeout: 10000}).type("Mike Johnson")

4.Use cy.intercept() to wait for the XHR request to finish execution. Here I am assuming that there is some unfinished XHR request after clicking the modal button that is causing the issue. If that is not the case, you can debug your tests to find out and apply intercept accordingly.

it("Can fill out form and submit", () => {
    cy.intercept('http://example.com/settings').as('getSettings') //Intercept the url that is triggered after clicking the modal button
    cy.get("#modal-button").click()
    cy.wait('@getSettings') //Wait till that request has finished execution
    cy.get("#modal-form").should("exist")
    cy.get("#form-name").type("Mike Johnson")
    cy.get("#form-age").type("33")
    cy.get("#form-email").type("mj09@yahoo.com")
    cy.get("#submit-button").click()
})

Why don't you directly target the input field using the following code

cy.get('input[name="teacher[0].number"]').type('8000-1612023')

Please find the screenshot below for a successful test. I would also recommend you to change the type of input in your HTML to tel

HTML:

<input required="" type="tel" name="teacher[0].number" value="">

Cypress:

describe('Trial', function() {
  it('Test', function() {
    cy.visit('http://localhost:8080/trials/')
    cy.get('input[name="teacher[0].number"]').type('8000-1612023')
  })
});

Test Result:

cy.get(partnerPriceField).should('have.value', 75) is preferred for e2e tests.

The job of testing the calculation falls to unit tests, which are close to the source code so test can be changed if/when the src calculation changes.

The job of e2e test is to make sure that given some input data the page shows the output data (black box).

Preferably input and output are supplied in a fixture table that's easily adjusted when the calculation is revised.

yarn internally uses sh to execute the commands given in the scripts (cmd in case of windows) - Source. This is very similar to what npm does as well.

Here && is handled by a shell, so your command yarn percy:local && yarn start:server percy:exec is run as 2 separate child processes. This means yarn percy:local runs in a process and sets the env variables as desired in its context but the second process which is running yarn start:server percy:exec has no idea about the env variables set by process 1.

Lets see how OS X handles this:

1. With &&

sh -c 'PERCY_TOKEN=asdfasdf; PERCY_BRANCH=local' &&  sh -c 'echo $PERCY_TOKEN'

This prints nothing

2. Without &&

sh -c 'PERCY_TOKEN=asdfasdf; PERCY_BRANCH=local echo $PERCY_TOKEN'

This prints asdfasdf

I think removing the && in the cy:percy:local should fix your issue.

Edit: Solution for your particular situation as discussed in comments

As explained in the 2nd point of this answer: stackoverflow.com/a/37141993/8266093 I would suggest you run this script in the format ENV_KEY1=value1 ENV_KEY2=value2 command which in your case becomes PERCY_TOKEN=$(grep 'PERCY_TOKEN.*' .env | sed 's/.*=//') PERCY_BRANCH=local yarn percy exec cypress run. Along with this, you can add your start-server yarn command as well if running it separately is not a solution for you.