How to use addOrUpdateSelectorPlaygroundHighlight method in Cypress

To make sure the value of number is passed on to the type, you have to add a then, something like:

let number

describe('some test', () => {
  before(() => {
    cy.clearCookies()
  })
  it('some test', () => {
    cy.someCommand()
    clientPage.someMethod()
    cy.intercept('**/request').as('idNumber')
    clientPage.someMethod1()
    cy.wait('@idNumber')
      .then((res) => {
        number = res.response.body.numbers.id
      })
      .then(() => {
        cy.get('#someELement').type(number)
      })
  })
})

If you want to use the variable globally throughout the project, you can use the Cypress.env() method. Cypress Docs.

describe('some test', () => {
  before(() => {
    cy.clearCookies()
  })
  it('some test', () => {
    cy.someCommand()
    clientPage.someMethod()
    cy.intercept('**/request').as('idNumber')
    clientPage.someMethod1()
    cy.wait('@idNumber').then((res) => {
      cypress.env('number', res.response.body.numbers.id) //Sets Number
    })
    cy.get('#someELement').type(Cypress.env('number')) //Gets Number and types it
  })

  it('some different test', () => {
    cy.get('#someELement').type(Cypress.env('number')) //types the number
  })
})

I managed to solve this by using a Promise;

Doing some further reading, I found out the then function I am executing is synchronous (I'm new to JS, pls don't hurt me).

I refactored the then function to the following:

.then((response) => {
        return new Promise(resolve => {        
            expect(response).property('status').to.equal(200)
            expect(response.body).property('id').to.not.be.oneOf([null, ""])
            const respBody = response.body;
            boardId = respBody['id']
            resolve(boardId)
        })

It's probably not entirely correct or best practice, but it will do for my demo

You can do something like this:

cy.assertObjectIsFocused(
  selector[Cypress.env(common.APP_NAME)].newPlayer.btnNextEpisode
)
cy.get(selector[Cypress.env(common.APP_NAME)].newPlayer.btnNextEpisodeLabel)
  .invoke('attr', common.TEXTURE_TEXT)
  .as('nextEpisodeLabel')

...

cy.get('@nextEpisodeLabel').then((label) => {
  cy.wrap(label).should('match', /S\d+ E\d+/)
  cy.get(
    selector[Cypress.env(common.APP_NAME)].newPlayer
      .playerAssetEpisodeAndSeasonNumbers
  )
    .invoke('attr', common.TEXTURE_TEXT)
    .should('contain', label)
})

Or, if you want to add the alias based on whether the extracted label matches the regex or not, You can do like this:

cy.assertObjectIsFocused(
  selector[Cypress.env(common.APP_NAME)].newPlayer.btnNextEpisode
)
cy.get(selector[Cypress.env(common.APP_NAME)].newPlayer.btnNextEpisodeLabel)
  .invoke('attr', common.TEXTURE_TEXT)
  .then(($nextEpisodeLabel) => {
    if ($nextEpisodeLabel.match(/S\d+ E\d+/)) {
      cy.wrap($nextEpisodeLabel).as('nextEpisodeLabel')
    }
  })

...

cy.get('@nextEpisodeLabel').then((label) => {
  cy.get(
    selector[Cypress.env(common.APP_NAME)].newPlayer
      .playerAssetEpisodeAndSeasonNumbers
  )
    .invoke('attr', common.TEXTURE_TEXT)
    .should('contain', label)
})

If you are using {force: true} then it doesn't matter if the element is visible or hidden, cypress will click it. So in my opinion you don't need the filter option.

cy.get(`[data-cy="${test}"]`).click({force: true})

Or, If you want to directly apply the OR condition in .filter you can do:

cy.get(`[data-cy="${test}"]`).filter(':visible,:hidden').click({force: true})

Or, If you want to use If-Else you can do something like this:

cy.get(`[data-cy="${test}"]`).then(($ele) => {
  if ($ele.filter(':visible')) {
    cy.wrap($ele).click()
  } else if ($ele.filter(':hidden')) {
    cy.wrap($ele).click({force: true})
  }
})

The example you're giving can be solved by implementing a custom fixture. Fixtures are @playwright/test's solution to customizing/extending the test framework. You can define your own objects (similar to browser, context, page) that you inject into your test, so the test has access to it. But they can also do things before and after each test such as setting up preconditions and tearing them down. You can also override existing fixtures.

For more information including examples have a look here: https://playwright.dev/docs/test-fixtures

This code will yield the DOM element with YOUR_BUTTON_CLASS which contains text 'Customer'. Is that what you're looking for?

cy.get('.YOUR_BUTTON_CLASS').contains('Customer');

Here the documentation for .contains cypress command.

From the question and the comments above, it sounds like you're trying to do something like this:

1. set up your application
2. click a button (or do something else) to start a request to an API
3. capture the response from the API
4. use the response to test something else in your application (perhaps make sure some text changes on the page?)

While it is possible to write tests in this way, there is a problem with this: the response from the API may change depending on circumstances outside your control. For example, what happens if you're working on your project and the API happens to be down that day? Your code is going to break and it won't be due to a bug in your code. In fact, you won't be testing your code at all (at least not the code you thought you were testing), because you won't be getting the response you want from the API.

This is why Cypress provides a way to stub the requests - to make sure that when your tests are running, you are getting the response you want from the API. If you want to write a test to see what happens when the API returns value A, you need to make sure the API doesn't return value B. Stubbing the requests allows you to make sure the application gets value A when you need it to.

So the examples you've seen probably do something like this:

1. set up your application
2. use cy.route to stub the API requests to return a known value
3. click the button - your app now makes a request and gets back that known value
4. test your application to make sure it does what you expect when it gets that known value.

If you have a range of different response values for which you want to test your app's behaviour, write a set of tests, one for each value.

You could use the Navigation Timing API:

In your test you will need to assert something like:

expect(performance.navigation.type).to.equal(performance.navigation.TYPE_RELOAD);

I had the same question, and couldn't quite square the accepted answer with what I saw happening (in Cypress 9.2.1).

It turns out that when a .js file is given as a fixture, cypress eval()s the content of the file (actually, it uses eval-with-parentheses), and uses whatever object this results in. So it is possible to have a file user-details.js, which looks like

[{name: "Bob", age: 30 + 5}]

or even execute some "real" code:

["Bob", "Rob", "Job"].map((name, index) => ({user: name, age: 20 + index}))

or

(() => {
    const users = ....
    return users
})()

It should be noted that it's not as flexible as you might want (e.g. you cannot import code, do asynchronous things, etc), but it's more than nothing.

The question is, should you....

Quite honestly, I think this is a great way to allow making your fixtures slightly more human readable, being able to add comments, and easy conversions. And you're not bothered by JSON's comma-stictness E.g

[
  // have a single user, because blah blah
  {name: "Bob", date_of_birth: new Date(1979, 5, 3).valueOf() / 1000},
]

(Date(1979, 5, 3) is much better human-readable than some unix timestamp (even though it means 5th of June, not 5th of May....))

I fully think that the .js fixture is a good way to do this (and would be even happier if it would just import the fixture as a module and use the default export as item or something, but eval is acceptable....), as long as the thing you're producing is constant! If you want something dynamic (or, probably, something constant that takes a bit more complexity to make), you're much better of with @seth-lutske 's suggestion (meaning that in your case, the accepted answer is what you need, however I wanted to document how .js fixtures work in case someone else came by).

Having said all this, it's questionable why cypress uses an eval() here, even though the suggested way is to use window.Function(); in addition, I wonder if you want to run the risk that down the line, some other developer (which includes future-you) decides to build a system that downloads your fixtures from some external website, which means that you created a nice security hole....

It's very informative to read the github issue on Javascript fixtures (I wish I had before I dove into all this myself); if you're looking for a good workaround, see this and this comment.

As a concrete answer to the question asked, the problem is that

eval(`data = {
  email: function () {
    const currentTimestamp = new Date().getTime();
    return \`test\${currentTimestamp}@test.com\`
  },
  firstName: 'Max',
  lastName: 'Mustermann',
  street: 'Some Street',
} `)

will return exactly that object, which should be accessible on this.userDetails. Therefore this.userDetails.data points to the data-field in this object, which is undefined.

The following would work:

user-details.js:

{
  data: {
    email: function () {
      const currentTimestamp = new Date().getTime();
      return `test${currentTimestamp}@test.com`
    },
    firstName: 'Max',
    lastName: 'Mustermann',
    street: 'Some Street',
  }
} 

(or, in case you want email to be a string rather than a function:

{
  data: {
    email: (function () {
      const currentTimestamp = new Date().getTime();
      return `test${currentTimestamp}@test.com`
    })(),
    firstName: 'Max',
    lastName: 'Mustermann',
    street: 'Some Street',
  }
} 

)