How to use injectStylesInlineForPercyInPlace method in Cypress

Try something like this, testing for span with jQuery

cy.get('body').then($body => {
  const $span = $body.find(`span[data-test^="${key}-${variant}-"]`)
  if ($span.length === 0) {
    cy.log('Nothing found')
    return
  }
  if ($span.attr('data-test').split('-')[3] === 'error') {
    throw 'error'
  }
  if ($span.attr('data-test').split('-')[3] === 'success') {
    return  
  }
  cy.log($span.attr('data-test'))
})

If you want to capture the transitory element that may or may not appear, use a recursive function

function eatSnack(level = 0) {

  // Figure out how many times you want to check before giving up
  if (level === 10) {
    cy.log('Nothing found')
    return
  }

  cy.get('body').then($body => {
    const $span = $body.find(`span[data-test^="${key}-${variant}-"]`)

    if ($span.attr('data-test').split('-')[3] === 'error') {
      throw 'error'
    }
    if ($span.attr('data-test').split('-')[3] === 'success') {
      return  
    }
    if ($span.attr('data-test').split('-')[3] === 'warning') {
      cy.log($span.attr('data-test'))
      return
    }
    if ($span.attr('data-test').split('-')[3] === 'info') {
      cy.log($span.attr('data-test'))
      return
    }

    cy.wait(10)        // adjust this to suit SnackBar
    eatSnack(++level)  // try again
  }
})

eatSnack()  // start looking

You should use cy.url() to get the current url of the app you're testing.

for example

cy.url().then(url => console.log(url))

The app url is shown above your test page. See here

You can access an array item (in your case it's the object) using the index position (in your case it's zero)

cy.get(".gLFyf").type(this.lead.result.records[0].Id)

At Pactflow, we've spent about 6 months using Cypress and Pact together, using the Pact mock service to generate pacts from our Cypress tests as suggested in https://pactflow.io/blog/cypress-pact-front-end-testing-with-confidence/

We have this week decided to change our approach, for the following reasons.

1. Our Cypress tests are much slower than our unit tests (15+ minutes), so generating the pact, and then getting it verified takes a lot longer when we generate the pact from our Cypress tests vs our unit tests.
2. Our Cypress tests can fail for reasons that are not to do with Pact (eg. layout changes, issues with the memory consumption on the build nodes, UI library upgrades etc) and this stops the pact from being generated.
3. The Cypress intercept() and mock service don't play very nicely together. Any request that does not have an explicit intercept() for Cypress ends up at the mock service, and every time a new endpoint is used by the page, the request hits the mock service, which then fails the overall test, even if that endpoint was not required for that specific test.
4. When a Cypress test fails, there is very good debugging provided by the Cypress library. When it fails for reasons to do with Pact, it's currently hard to identify the cause, because that information is not displayed in the browser (this could potentially be improved, however, it won't mitigate the already listed issues).

Our new approach is to generate our Pacts from our unit tests (instead of our Cypress tests) and to share the fixtures between the unit and Cypress tests, using a function that strips of the Pact matchers. eg.

const SOME_INTERACTION = {
  state: 'some state',
  uponReceiving: "some request",
  withRequest: {
    method: "GET",
    path: "/something"
  },
  willRespondWith: {
    status: 200,
    body: {
      something: like("hello")
    }
  }
}

Unit test

describe('Something', () => {
  let someProviderMockService
  beforeAll(() => {
    someProviderMockService = new Pact({
      consumer: 'some-consumer',
      provider: 'some-provider'
    })
    return someProviderMockService.setup()
  })
  afterAll(() => someProviderMockService.finalize())
  afterEach(() => someProviderMockService.verify())

  describe('loadSomething', () => {
    beforeEach(() => {
      return someProviderMockService.addInteraction(SOME_INTERACTION)
    })

    it('returns something', async () => {
      const something = await loadSomething()
      //expectations here
    })
  })
})

Function that turns the Pact interaction format into Cypress route format, and strips out the Pact matchers.

const Matchers = require('@pact-foundation/pact-web').Matchers

// TODO map the request body and query parameters too
const toCypressInteraction = (interaction) => {
  return {
    method: interaction.withRequest.method,
    url: Matchers.extractPayload(interaction.withRequest.path),
    status: interaction.willRespondWith.status,
    headers: Matchers.extractPayload(interaction.willRespondWith.headers),
    response: Matchers.extractPayload(interaction.willRespondWith.body)
  }
}

In the Cypress test

cy.route(toCypressInteraction(SOME_INTERACTION))

This approach has the following benefits:

1. The pact is generated quickly.
2. The pact is generated reliably.
3. The Cypress tests are more reliable and easier to debug.
4. The requests used in the Cypress tests are verified to be correct.
5. There is less chance of "interaction bloat", where interactions are added merely to test UI features, rather than because they provide valuable coverage.

I hope this information is helpful for you. We now recommend this approach over direct use of the mock service in Cypress tests.

A simple workaround: in plugins/index.js do

module.exports = (on, config) => {
  if(config.hasOwnProperty('env') &&  config.env.hasOwnProperty('baseUrl')){
      config.baseUrl = config.env.baseUrl;
  }
  return config
}

The easiest way to make access to the campArr synchronous with the assignment is to use a then callback:

it('Action -> delete -> check list of camapaigns to delete',function(){
    let campArr=[]
    
    cy.get('md-checkbox').then((box)=>{
        for(let i=1;i<box.length;i++){
            cy.get(`.md-body > :nth-child(${i}) > :nth-child(3)`).then(($el)=>{
                let elToText=$el.text()
                campArr[i-1]=elToText
            })
        }
    })
    cy.log(campArr.length)
    cy.get('md-checkbox').eq(0).click()
    cy.get('.btn-group>button').eq(0).click()
    cy.get('.dropdown-menu-left > :nth-child(3) > .ng-binding').click().then(() => {
       cy.log(campArr[0])
       for(let i=0;i<campArr.length;i++){ 
           cy.get(`div.ng-scope > ul > :nth-child(${i+1})`).should('contain.text',campArr[i])
           cy.log('checked')
       }
    }
})

tl;dr

Just pass the timeout to get, it will pass it down to should.

cy.get('body', {timeout: 30000}).should('contain','success')

Explanation

This is explained in should's official documentation in the Timeouts section:

.should() will continue to retry its specified assertions until it times out.

cy.get('input', { timeout: 10000 }).should('have.value', '10')
// timeout here will be passed down to the '.should()'
// and it will retry for up to 10 secs

The technique is explained in greater detail in the docs about timeouts.

There is an example in the Cypress Real World App, a payment application to demonstrate real-world usage of Cypress testing methods, patterns, and workflows

There are 3 transaction feeds and each are tested thoroughly in this spec: https://github.com/cypress-io/cypress-realworld-app/blob/develop/cypress/tests/ui/transaction-feeds.spec.ts

All the code and referenced modules in index.js are loaded before your test file. So you need to refer(require) commands.js in your index.js file. You can however import commands.js module directly in your test file but then you need to include it every test file. Recommended approach is to include it in index.js file and you are not worried about explicitly refer in your test files.