How to use getLogPath method in Cypress

From the docs,

Results XML filename can contain [hash]

Also, if you check the junit reporter source, you can see how is doing it:

...
this.writeXmlToDisk(xml, this._options.mochaFile);
...

MochaJUnitReporter.prototype.writeXmlToDisk = function(xml, filePath){
  if (filePath) {
    if (filePath.indexOf('[hash]') !== -1) {
      filePath = filePath.replace('[hash]', md5(xml));
    } ...

So, you could just have:

"mochaFile": "./cypress/results/my-test-output[hash].xml"

This is a pretty broad topic but I have some things that I think would be helpful to you. Comment on this answer if you would like me to clarify or add something.

Identify repeating words and consolidate
One example would be "cart". If that word is repeated at the beginning of every test spec, then create a directory called cart and put all the cart test specs in there. Nesting various things in this fashion can be helpful. If the file is located in a directory called "cart", you can remove it from the name.

Don't over/under nest
Trying to over organize can leave you more confused. Those Matryoshka_dolls come to mind(https://en.wikipedia.org/wiki/Matryoshka_doll). Nest things as you need to. The same is true for abstracting things into page objects. Over or under abstracting can make things more confusing.

Avoiding cascading failures
Be careful not to write you test in a way that if one it fails, the following its will fail. You also won't get proper retires if you don't respect potential cascading failures. This is a double edged sword as well. If you only have one it per spec, test execution times will grow. If you have made good decisions with how you break apart your test specs and still need to improve execution time, look into parallelization: https://docs.cypress.io/guides/guides/parallelization.html#Splitting-up-your-test-suite

Shared/Common methods
You can use Page Object Modeling(acceptable to use but sometimes referred to as an unnecessary abstraction/anti-pattern) to make your code reusable. Basically you have external files that you pull in(as an instance to allow for parallelization) and reference those methods in your test specs so that your test can remain DRY(Don't Repeat Yourself). Your fellow developers will respect your effort to follow the Object Oriented Programing Principals. DRY is one of them.

Cucumber for ease of reuse and readability
Consider using Cucumber syntax/testrunner if you have a ton of repeating test logic with different permutations. Each "step" or Given/When/Then is backed by code. You can use regex to allow for parametrization.

Hope this helps! Organization is something you will continually revist and refactor your code. Each team will have different needs. Approach this in a very collaborative fashion with all interested parties providing feedback. Godspeed!

You can use tasks to execute node code. In your plugins.js create the task with the arguments you need, returning the calculated value:

  on('task', {
    // you can define and require this elsewhere
    getTicketBySummary('getTicketBySummary', { issues, summaryTitle }) {
      return issues.data.issues.filter(...);
    }
  })
}

In your test, execute the task via cy.task:

  it('returns an array containing a found ticket summary', () => {
    cy.task('getTicketBySummary', {
      issues: mockedTickets,
      summaryTitle: 'This is ticket number 1',
    }).then(result => {
      expect(result).eq(mockedTickets.data.issues[0]);
    })
  });

That being said, getTicketBySummary looks like a pure function that doesn't depend on fs. Perhaps separate helper functions that actually need node as that could avoid need cy.task. If you want to be able to import commonjs (require) via ES6 import/export you would usually need to setup build tools (babel/rollup/etc) to be able to resolve that effectively.

Hopefully that helps!

I just found another approach in a blog, adding it here for reference.

const uuid = () => Cypress._.random(0, 1e6)
const id = uuid()
const testname = `testname${id}`
cy.get('input').type(testname);

worked well for me :)

Some more ideas:

On-the-fly retry changes

TLDR
Upside: simple
Downside: uses internal commands

There's an internal command that will allow you to change the retry count mid-test.

I stress the word internal as a warning that it may stop working at some new release.

With your code

export class Login {
  ...

  login(email, password) {

    const originalRetries = cy.state('runnable')._retries

    cy.state('runnable')._retries = 5    // WARNING - internal command
    
    this.username_input().type(email);
    ...

    cy.state('runnable')._retries = originalRetries  // restore configured retries value
  }
}

Retry by recursion

TLDR
Upside: good for flaky situations
Downside: explicit wait required

If you want the longer but more mainstream solution, use recursion.

You will need a non-failing check to handle the retry-or-finish logic, which will essentially mean changing cy.get('.profile-content').should('exist') to a jQuery equivalent and using an explicit wait (a downside for this pattern).

export class Login {
  ...

  loginAttempt(attempt = 0) {       
    
    if (attempt === 3) throw 'Unable to login after 3 attempts'

    this.login_button().click();
    
    // wait for login actions to change the page
    cy.wait(200).then(() => {  
      
      // test for success
      if (Cypress.$('.profile-content').length > 0) {
        return // found it, so finish
      }

      // retry
      loginAttempt(email, password, ++attempt)  
    })
  }

  login(email, password) {
    this.username_input().type(email);  
    this.password_input().type(password);
    loginAttempt()
    return this
  }
}

You can cut the cy.wait(200) down a bit and raise the maximum attempt, say cy.wait(20) and if (attempt === 300)

The downside is each retry uses up a bit more heap memory, so taking that too far will be detrimental - you'll need to experiment.

Set logged-in state directly

TLDR
Upside: By-passes flaky parts of test
Downside: Requires knowledge of login state

The other aspect you may consider is to cut out the flaky login altogether. To do that, you need to find out what the app considers to be logged-in. Is it a cookie, localstorage value, etc.

For each test that needs to be in logged-in state but is not actually testing the login process, set that state directly.

An example is given here recipes - logging-in__using-app-code

describe('logs in', () => {
  it('by using application service', () => {
    cy.log('user service login')

    // see https://on.cypress.io/wrap
    // cy.wrap(user promise) forces the test commands to wait until
    // the user promise resolves. We also don't want to log empty "wrap {}"
    // to the command log, since we already logged a good message right above
    cy.wrap(userService.login(Cypress.env('username'), Cypress.env('password')), {
      log: false,
    }).then((user) => {
    // the userService.login resolves with "user" object
    // and we can assert its values inside .then()

      // confirm general shape of the object
      expect(user).to.be.an('object')
      expect(user).to.have.keys([
        'firstName',
        'lastName',
        'username',
        'id',
        'token',
      ])

      // we don't know the token or id, but we know the expected names
      expect(user).to.contain({
        username: 'test',
        firstName: 'Test',
        lastName: 'User',
      })
    })

function login (username, password) {
  const requestOptions = {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  }

  return fetch(`${config.apiUrl}/users/authenticate`, requestOptions)
  .then(handleResponse)
  .then((user) => {
    // login successful if there's a jwt token in the response
    if (user.token) {
      // store user details and jwt token in local storage to keep user logged in between page refreshes
      localStorage.setItem('user', JSON.stringify(user))
    }

    return user
  })
}

maybe you can this this try when using cy.request pretty much like the usual way you use restful in cy.request

example your query name is findUser with variable of username your query should look something like findUser(username:"hello"){id, name} and so on

but instead of just this, you need to pass it as json if it is a query then it'll be {"query": findUser(username:"hello"){id, name}} this will actually be your body.

an example is below...

const query = `{
  findUser(username:"hello") {
    id
  }
}`;
    
cy.request({
  url: 'http://localhost/graphql/',  // graphql endpoint
  body: { query },                   // or { query: query } depending if you are writing with es6
  failOnStatusCode: false            // not a must but in case the fail code is not 200 / 400
}).then((res) => {
  cy.log(res);
});

There's a suggestion from Cypress [here] that may help:

I believe that clearing the AppData may solve the problem. To do this:

• open up the cypress app
• Go to File -> View App Data
• Delete everything in here
• Close cypress and open it up again

And it should recreate all the browser profiles + extension

If that does not work, the problem is probably with the chrome install itself, try uninstalling / reinstalling it.

You can also pick up Chrome Dev, install it and Cypress will show that as a separate option.

If your project uses Babel, you should be able to use babel-plugin-react-remove-properties to remove data-cy and any other attributes/properties you want to hide away.

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.