How to use matcherFromGroupMatchers method in Cypress

I know conditional testing is not recommended, but I dont have an option now.

Yes, you do have an option. I apologize up front, this is not a quick, easy answer. Conditional testing in cypress can be tricky, however, when you do understand it, your tests will be better for it. You do have a better option and I'm going to try my best to explain it, so here goes.

For situations like this, you have to adjust the way that you approach the problem. At the moment, you're basing your condition on the UI element which, as Cypress documentation states, will lead to exploding kittens. No one wants exploding kittens. What you want to do instead is change the source of truth your condition is based on from using the UI element to basing your condition on something more stable, like server response.

For me, personally, this was incredibly difficult to wrap my brain around how to actually do this in practice, so I'll try my best to explain.

So, currently, you're doing something like:

• Request is made (#of questions) and page loads and view is set based on response.
• If UI element is on page (4th question), then test button

What you want instead is:

• Request is made (how many questions?)
• Capture response from request with cy.route("someAlias") and cy.wait('@someAlias')
• Your response from the server is the information that your UI elements are building themselves from. Base your condition on this instead. (see Routes & Aliases)

So your condition would be something like:

if questions returned in response > 3 then test button.

The theory here is, your server is a solid source of truth which has all the info you need, right up front. The DOM (UI elements) is not because it does not have all of the info you need up front and there is no guarantee at the time of your condition that it will have resolved the stuff you need in order to proceed.

If your server responds with more than 3 questions, there should be a button there. Switching the logic here makes your test more stable and you're actually testing the thing that you want to test. When you've got more than 3 questions, you should have a button. Not if there are more than three UI elements, then you should have a button. There is no guarantee that your button will have resolved by the time your condition is met for the UI elements. Your server response should be your source of truth, not the UI elements.

I don't know the logic that you have that makes the request so my answer isn't exact, however, let's assume that on page load, there is a request to /questions that responds with the questions that you're talking about (3 or 4). Your code would then look something like this:

// setup the route to wait for
cy.server();
cy.route("/questions").as("questions");
// do whatever you do that sends that request
cy.visit("/pageOfQuestions");
// wait for request and grab response using route alias
cy.wait("@questions").then(function(xhr) {
  // find your path (I'm guessing here) to the info you need and test condition
  // the condition and the path to the info will vary based on what your response 
  // actually contains
  if(xhr.response.questions.length > 3) {
    // test your button-y stuff here
    cy.get(`button[name="cosmeticDamage"][value="${cosmetic}"]`).click();
  } else {
    cy.log("nothing to test");
}

The difference is when you base your condition (source of truth) on the UI elements, the DOM does not always resolve itself in the manner you expect. When you reach the condition (in this case the question UI elements), other things still haven't resolved themselves (button UI elements). You have to wait for two elements to align in the DOM -> Your source of truth (condition) and the UI element you want to test (button). Often, one hasn't loaded when the other has and you cannot rely on them loading consistently which is why cypress recommends never basing conditions on UI elements, unless you like exploding kittens.

Explained differently, let's say the DOM has 10 resources to load. You're saying to cypress: if resource #7 looks like this then play with resource #1

Cypress goes and waits for resource 7. When it's ready it checks that the condition is met and then tries to play with resource 1... which the DOM possibly hasn't resolved yet. And actually, sometimes it could be loaded but you can never guarantee that it will be which will lead to flaky tests.

When you base your source of truth on the server response, you're only waiting for and testing the one UI element and the cypress built-in time outs can successfully wait for that one element to load without depending on another. On page load, did the server give us more than 4 things? Then play with UI element

If there's anything I can clarify, just ask.

Reference:

• Conditional testing
• Routes and Aliases

If you use a specific array in your test code, you can easily get the length of the array by using the .lenght and access its elements by using the for loop.

I would not use .each(), only one will pass but any other will fail.

Use .contains() if your text is specific enough (not in multiple options)

cy.contains('[id="names"] option', 'Have This Name')  // fails only if 
                                                      // no option has the text

If you have to match exactly, filter the options

cy.get('[id="names"] option')
  .filter((idx, el) => el.innerText === 'Have This Name')  // fails if filter 
                                                           // returns 0 items

If you want .each() for another reason, this will do

let found;
cy.get('[id="names"] option')
  .each(($option) => {
    if ($option.text() === 'Have This Name') {
      found = $option
      return false // return now, have found it
    }
  })
  .then(() => {    // after loop exit
    expect(found).to.have.text('Have This Name')
  })

You could use jquery operators to check the existence of an element and wrap that function as below, adding to your support.js file:

Cypress.Commands.add("checkIfClassExists", (classToFind) => {
    return Cypress.$(classToFind).length>0
})

Then in your tests:

if (cy.checkIfClassExists('.okrSelectorSelect__value-container')) {
    //do something
} else {
    //do nothing 
}

cy.contains Requires argument as string. Seems like you need to pass the argument to the ,contains() in the function chooseAppointmentDate(value)

class NewAppointment {
    
    selectSeverity(value) {
        cy.get("#severities").select(value)
    }

    chooseAppointmentDate(value) {
        cy.get("[data-handler='selectDay']").contains(value).click()

    }
}
export default NewAppointment

As far as I know, no --- it's not required when you run Cypress from a binary.

Cypress runs on Electron, which bundles Node.js in.

As for cy.task etc., it communicates with Cypress' own background node.js process (from Electron), not one that would be supplied by host (your) environment.

By default, Cypress will wait for your page to load all resources before continuing the test. Your cy.wait() shouldn't be necessary. The default timeout for cy.visit() is 60 seconds.

Also, cy.get() will retry finding your element until the element exists. The default timeout is 4 seconds, but you can increase it.

Something like this is generally all you need:

describe('Update Case', () => {
  it('Create Case', () => {   
    cy.visit(targeturl)
    cy.get('button').contains('Create').click()

If you find that this isn't working, perhaps because your page takes more than 4 seconds to render after it loads all resources, then you can do something like this:

describe('Update Case', () => {
  it('Create Case', () => {   
    cy.visit(targeturl)
    // wait up to 30 seconds for some element to exist before continuing the test
    cy.get('.some-element-in-your-app-that-only-exists-once-page-has-loaded', { timeout: 30000 })
    cy.get('button').contains('Create').click()

In general, you shouldn't ever need to use cy.wait() to delay your tests by a certain number of milliseconds. Doing so is almost always a bad practice.

If by global var you mean const coordinates = or let coordinates = or var coordinates = , then you can expose a reference to the variable on window, which is a global context that is common to both the app and the test.

In the app

const coordinates = {x:1, y:2}
if (window.Cypress) {            // if window.Cypress is defined then we are testing 
  window.coordinates = coordinates
}

In the test

cy.window().then(window => {
  expect(window.coordinates).to.deep.eq({x:1, y:2})    // passes
})

You mention this code for obtaining the value in version.

let version; 
getVersion((setVersion) => {   
  version = parseInt(setVersion.replace(/[v.]/g, ''));   
  console.log(version); //8203 
});
if (version < 8203) {  ??? is this where you test ???

If the above pattern is how your test looks, I'd say the getVersion() callback has not completed before the if() is evaluated.

Does this structure improve things?

let version; 
getVersion((setVersion) => {   
  version = parseInt(setVersion.replace(/[v.]/g, ''));   
  console.log(version); //8203 

  if (version < 8203) {  
    ...
  }
  else {
    context('Testing Feature', () => {
      it('Test 1', () => {
      ...
    });
  }
});