How to use runFailingProjectTest method in Cypress

I'm not sure about your Wordpress site, but the following worked for the Material-UI site referenced in Cypress scrolling behaviour on get and relative positionning

.scrollIntoView() offset should be negative

it('make Elvis appear', () => {
  cy.viewport(750,480)
  cy.visit('https://mui.com/getting-started/templates/dashboard/');

  cy.contains('Elvis Presley').scrollIntoView({offset:{top: -100}})
}) 

use native scrollIntoView

it('make Elvis appear', () => {
  cy.viewport(750,480)
  cy.visit('https://mui.com/getting-started/templates/dashboard/');

  // https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView
  cy.contains('Elvis Presley')
    .then($el => $el[0].scrollIntoView(false)) // scrolls $el to bottom
})

make header transparent

it('make Elvis appear', () => {
  cy.viewport(750,480)
  cy.visit('https://mui.com/getting-started/templates/dashboard/');

  cy.get('header').invoke('css', 'opacity', '0')
  cy.contains('Elvis Presley').scrollIntoView()
})

using .scrollTo()

This command applies to the scroll container, not the element you target, so the positioning may not come out correctly every time.

function getScrollParent(node) {
  if (node == null) return null;

  if (node.scrollHeight > node.clientHeight) {
    return node;
  } else {
    return getScrollParent(node.parentNode);
  }
}

it('make Elvis appear', () => {
  cy.viewport(750,480)
  cy.visit('https://mui.com/getting-started/templates/dashboard/');

  cy.contains('Elvis Presley')
    .then($el => {
      const scrollParent = getScrollParent($el[0])
      cy.wrap(scrollParent).scrollTo('center')
    })
})

Chai lt is valid (see Chai.js cheatsheet), but it requires numeric values and <input /> value is always a string, so you will need to convert it to a number.

Also, the Cypress .should('have.value.lt', '201') command is a combination of jQuery and chai operators, which from the error message is obviously illegal (the syntax for should params is a bit opaque, you just have to try things out).

So, this works

cy.get('.number-input').type('200')
  .invoke('val')                         // call the val() method to extract the value
  .then(val => +val)                     // convert it to a number
  .then(val => console.log(typeof val))  // just to check the type
  .should('be.lt', 201)                  // also compare it to a number

It's been 2 years that this questions was submitted, but for those who still encounters that error, Cypress provides a guide about Okta e2e testing: https://docs.cypress.io/guides/end-to-end-testing/okta-authentication#Adapting-the-back-end

The solution is here: https://github.com/cypress-io/cypress/issues/7402 You have to upgrade cypress to version 4.6.0 and add

{
    "experimentalSourceRewriting": true
}

to cypress.json

This comes up frequently. Cypress has some documentation stating Commands are not Promises. I did a write up using a custom command to force a Command Chain to behave like a promise, but it is still experimental and nuanced.

First I'll give your example almost verbatim to what you're trying to accomplish:

cy.url().should('include', '/home').then(() => {
  cy.window().then(win => {
    console.log(win) // The window of your app, not `window` which is the Cypress window object
  })
})

Your example could be written a number of ways, but maybe explaining a bit how Cypress works will help more.

Cypress has something called "Commands" that return new "Chainers". It is fluid syntax like JQuery:

// fill and submit form
cy
  .get('#firstname')
  .type('Nicholas')
  .get('#lastname')
  .type('Boll')
  .get('#submit')
  .click()

You can (and should) break up chains to be more like sentences:

// fill and submit form
cy.get('#firstname').type('Nicholas')
cy.get('#lastname').type('Boll')
cy.get('#submit').click()

You might have guessed that all Cypress Chainer commands are asynchronous. They have a .then, but they aren't actually promises. Cypress commands actually enqueue. Cypress hooks into mocha's lifecycle to make sure a before, beforeEach, it, afterEach, after block waits until Cypress commands are no longer enqueued before continuing.

Let's look at this example:

it('should enter the first name', () => {
  cy.get('#firstname').type('Nicholas')
})

What actually happens is Cypress sees the cy.get Command and enqueues the get command with the argument '#firstname'. This immediately (synchronously) returns execution to the test. Cypress then sees the cy.type command with the argument 'Nicholas' and returns immediately to the test. The test is technically done at this point since there is no done callback and no Promise was returned. But Cypress hooks into the lifecycle of mocha and doesn't release the test until enqueued commands are completed.

Now that we have 2 enqueued commands and the test is waiting for Cypress to release the test, the get command is popped off the queue. Cypress will try to find an element on the page with an id of firstname until it finds it or times out. Assuming it finds the element, it will set a state variable called subject (cy.state('subject'), but don't rely on that). The next enqueued command type will grab the previous subject and attempt to type each key from the string 'Nicholas' one at a time with a default delay of 50ms until the string is done. Now there are no more enqueued commands and Cypress releases the test and the runner continues to the next test.

That was a bit simplified - Cypress does a lot more to make sure .type only runs on elements that can receive focus and are interactable, etc.

Now, knowing this, you can write your example a bit more simply:

cy.url().should('include', '/home')

// No need for `.then` chaining or async/await. This is an enqueued command
cy.window().then(win => {
  console.log(win)
})

Steve's answer actually helped me to end up with this code in cypress/plugins/index.ts.

import dotenv from 'dotenv';

dotenv.config({ path: '.env.local' });

import { encryptSession } from 'utils/sessions';

/**
 * @type {Cypress.PluginConfig}
 */
const pluginConfig: Cypress.PluginConfig = (on, config) => {
  on('task', {
    encryptSession: (session: {
      issuer: string;
      publicAddress: string;
      email: string;
    }) => encryptSession(session),
  });
};

export default pluginConfig;

Then in cypress/support/commands.ts.

Cypress.Commands.add(
  'loginWithCookie',
  ({
    issuer = 'some-issuer',
    publicAddress = 'some-address',
    email = 'some-email',
  } = {}) => {
    const session = { issuer, publicAddress, email };

    return cy.task<string>('encryptSession', session).then(token => {
      return cy.setCookie('my-secret-token', token).then(() => {
        return session;
      });
    });
  },
);

Run the tests from products list, and build the selector from it (since they have the same form)

const products = ['shoes', 'apparel', 'accessories']
it.each(products)(`verifies the main product groups (%s) and filters`, (product) => {

  const productTab = `[data-cy="main-group-tab.${product}"]`
  cy.get(productTab)
    .click();

  availabilityPage.productGroups()
                  .should('be.visible');

  availabilityPage.searchBar()
                  .should('be.visible');
});

I was able to solve this by

//cypress/support/index.js

Cypress.Server.defaults({
  ignore: xhr => {
    return Cypress.config().blockHosts.some(blockedHost =>  // get blockHosts from cypress.json using Cypress.config()
      Cypress.minimatch(new URL(xhr.url).host, blockedHost)  // if current url matches any blockedHost item, return true
    )
  }
})

more details on https://github.com/cypress-io/cypress/discussions/16536

There were changes that were made for within() in the version 5.4.0. Its mentioned in their changelog under bugfixes: