How to use openProject.closeBrowser method in Cypress

If you want to use the :has() pseudo-selector, you should do so on the outer of the .each() loop.

But please beware, :has() pseudo-selector will fail if there are zero buttons already clicked.

let myArray: any = []

cy.get('li[class="xyz"]:has(button[aria-label="remove"])')  // implied filter
  .each($li => {
    // only element with remove attribute inside here
    cy.wrap($li)
      .find('div[class="theText"]')
      .invoke('text')
      .then(text => {
        myArray.push(text)
      })
  })
}).then(() => {
  cy.wrap(myArray).as('myArray')
})

You can see your webpack logs by running cypress in debug mode documentation

Mac/Linux

DEBUG=cypress:* cypress run

Windows

set DEBUG=cypress:*
cypress run

It is quite a bit of output, as there's logging from everything cypress does - one of which is cypress:webpack, which can give you the full message.

If you're using VSCode, try using the Cypress Helper extension. It will handle some of this for you. After installing it, go into the extension settings, scroll to the botton, and you'll see the Type Definition On Save setting. Check that box, and it will generate the *.d.ts file entries based on your custom commands, every time you save.

After that, creating Intellisense text is as easy as writing JSDoc comments above your custom command, like so:

/**
 * Logs in the user
 */
Cypress.Commands.add('logIn', (email) => {
  doSomeLoginStuff()
})

Saving this results in the following code being added to a d.ts file in the same folder:

/**
 * Logs in the user
 */
logIn(email: any): Chainable<any>

Essentially you have an array of possible error messages, so you can test if the element's text exists within that array.

expect(['text_A', 'text_B']).to.include(el.text())

Another option that reads better would be to use .oneOf

expect(el.text()).to.be.oneOf(['text_A', 'text_B']);

https://docs.cypress.io/guides/references/assertions.html#BDD-Assertions

You should read the page called Introduction to Cypress from the Official documentation, or more generally everything under the "Core Concepts" menu. Most of these topics and concepts are explained there.

Command yields

Your assumption is correct, if you need the previous subject you need to use then since Cypress is async and doesn't return the subject. Instead it yields it. This is stated as a core concept of subject management:

Cypress commands do not return their subjects, they yield them. Remember: Cypress commands are asynchronous and get queued for execution at a later time. During execution, subjects are yielded from one command to the next, and a lot of helpful Cypress code runs between each command to ensure everything is in order.

The subject management section shows yielding examples:

Some methods yield null and thus cannot be chained, such as cy.clearCookies().

Some methods, such as cy.get() or cy.contains(), yield a DOM element, allowing further commands to be chained onto them (assuming they expect a DOM subject) like .click() or even cy.contains() again.

Each command yields something different. You can check this in the documentation for each command. For example, cy.children's yield section states that it returns a DOM element.

Technically you doesn't even need to add cy. before each command, since all of them return cy making every command chainable. Usually you only need to use .cy at the start of a command chain (like in the beginning inside a then block). This is more of a code style question.

Command execution

When you run the 3 cy.get lines the commands themselves are not going to be executed, they are just going to be added to a queue by Cypress. Cypress will track your commands and run them in order. Each command has a timeout and will wait for the command condition to be satisfied in that time frame.

As the Commands Are Asynchronous section states:

Cypress commands don’t do anything at the moment they are invoked, but rather enqueue themselves to be run later. This is what we mean when we say Cypress commands are asynchronous.

Technically I should cite the whole page of the documentation because it is really well structured, concise and detailed with a lot of example code. I highly recommend reading it.

Summary

In short, with cy. calls you queue up commands to run for Cypress. If you need to run your own synchronous code, or need the yielded subject you should add a .then() after the Cypress command you would like to run that code. You could write all your consecutive commands in a .then() but it is unnecessary, you just recreate the JS then Christmas tree of doom AKA the callback hell. So only use then if you need the yielded subject of the previous command or want to inject synchronous code. Of course, after some synchronous code (like an if condition) you need to call cy. again and they will be queued up inside that then. Whether you add your remaining cy. commands inside the then or one or more levels above, depends on if you need to work on top of the stuff happening inside the given then block or how you prefer to style your code. Here is an example from the docs modified for demonstration:

it('test', () => {
  cy.visit('https://app.com')
  // these lines will be queued up and will be run by Cypress in order
  cy.get('ul>li').eq(4)
  cy.get('.nav').contains('About')
  // we want to use the .user field's value
  cy.get('.user')
    .then(($el) => {
      // this line evaluates after the .then() executes
      let username = $el.text()
      // synchronous code to decide which commands to run (queue up)
      if (username) {
        // "queue up" other commands
        cy.contains(username).click()
        cy.get('ul>li').eq(2)
      } else {
        cy.get('My Profile').click()
      }
    })
  // command that doesn't depend on data inside the `then` block
  cy.get('.status').contains('Done')
})

If I understand correctly, you are looking for

cy.get('a[href="..."]')

Similarly

cy.get('img[src="..."]')

where you should add the appropriate text instead of ...

Of course, follow with .should('be.visible').

If you want to use a partial match, you can use

cy.get('img[src$="bottle.png"]')  // NOTE src$= 

You can use day.js to get the current date and format it accordingly.

const dayjs = require('dayjs')

//In test
cy.log(dayjs().format('DD/MM/YYYY'))  //Prints todays date 30/09/2021
cy.get('textfield').type(dayjs().format('DD/MM/YYYY')) //input today's date in DD/MM/YYYY format

Cypress commands are pushed (enqueued) into a queue (called the Command queue --- which is basically an array), and then executed serially (one after another), and asynchronously.

While your cy.log() will be executed asynchronously, too, after the previous command, the value you pass to it (page1value) is passed/evaluated synchronously, at the time you push the command to the queue (which is evaluated at the time the callback passed to it() is called --- at the beginning of the test).

This is just regular JavaScript behavior, and has nothing to do with Cypress. All the commands cy.* are just methods (functions) on the cy object, and they're called immediately. What is not called (executed) immediately, is the logic that each command does (e.g. query the DOM for the selector you supply to cy.get(), log to Command log when you call cy.log('string'), etc.).

Thus, in your 2nd example:

1. You declare page1value.
2. You then immediately enqueue commands cy.get(), cy.invoke, cy.then().
3. And you also immediately enqueue cy.log, to which you pass page1value (which at this time is still undefined).
4. After all commands are enqueued, they start to execute, from top to bottom. When the cy.then command takes turn to execute, the page1value variable is assigned, but it's no longer used (read) anywhere for the rest of the test (recall that you've already read it when you passed it to the cy.log command in the previous step).

Thus, what you want to do instead, is:

cy.get('#selector').invoke('text').then(text => {
  cy.log(text);
});

In your 3rd example, if you alias something, you need to access that value using another command (remember, everything is asynchronous, so you can't access values that are set asynchronously, in a synchronous manner as you're doing), in this case cy.get('@aliasName'):

cy.get('#selector').invoke('text').as('page1value');
cy.get('@page1value').then( value => {
  cy.log(value);
});

Note that the above explanations are slightly inaccurate and inexhaustive (there are more things going on behind the scenes), for the sake of simplicity. But as an intro to how things work, they should do.

Anyway, you should definitely read Introduction to Cypress.

You may also take a look at my older answers that touch on related concepts:

• How to use a variable as a parameter in an API call in Cypress
• In Cypress when to use Custom Command vs Task?

You must write a recursive promise function and check by yourself the color text, try the following

function checkColor(selector, color, maxWait, alreadyWaited = 0) {
  const waitTime = 500;
  // cy.get returns a thenebale
  return cy.get(selector).each((item)=> {
    // it checks the text right now, without unnecessary waitings
    if(!item.text() === color) {
      return false;
    }
    return true;
  }).then(result => {
    if(result) {
      // only when the condition passes it returns a resolving promise
      return Promise.resolve(true);
    }
    // waits for a fixed milliseconds amount
    cy.wait(waitTime);
    alreadyWaited++;
    // the promise will be resolved with false if the wait last too much
    if(waitTime * alreadyWaited > maxWait) {
      return Promise.reject(new Error('Awaiting timeout'))
    }
    // returns the same function recursively, the next `.then()` will be the checkColor function itself
    return checkColor(selector, color, maxWait, alreadyWaited);
  });
}

// then, in your test...
cy.addParameter('blue'); //Will send graphQL query to fetch the correct items. 
checkColor('data li', 'blue', 10000).then(result => {
  cy.get('data li').each((item)=> {
    cy.wrap(item).should('have.text', ' blue ');
  });
  // or
  expect(result).to.be(true);
});

I tried to comment a much as possible the code refactoring the code I developed for an accepted similar question.

Let me know if you need some more help ????

UPDATE

We (me and Tommaso) have written a plugin to help you with this kind of checks, its name is cypress-wait-until.

Please thank the Open Source Saturday community for that, we developed it during one of them Saturdays ????