How to use getBodyEncoding method in Cypress

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
  })
}

From your description the only step missing is the support file import.

// cypress/support/e2e.js
import '@cypress/code-coverage/support'

I also have a .babelrc with the following, but I believe you can do without it if just covering e2e tests.

{
  "plugins": ["istanbul"]
}

Let me know if that's not it, I will give you step-by-step.

You have to import the package:

support/index.js

import 'cypress-file-upload';

The alias you set are not like variables. Use a .then() to extract it's value.

You can also set http://localhost:3000 as baseUrl in cypress.config.js.

This is how your test would work:

cy.visit('/')
cy.get('.package-name').contains('Iniciante').invoke('text').as('name')

cy.visit('/pricing')
cy.get('.package-name').contains('Iniciante').invoke('text').as('name2')

cy.get('@name').then(name => {
  cy.get('@name2').then(name2 => {
    expect(name).to.be.eq(name2)
  ])
})

Since JavaScript runs asynchronously, So the below lines are executed before there is anything saved in your array.

cy.log(tableHeaders.indexOf("Tracking No.")) 
cy.log(tableHeaders.indexOf("Merchant Name")) 

To make sure that once your data is saved in the array and then only execute your cy.log statements you can use then().

let tableHeaders = []
cy.get('.rt-table > .rt-thead > .rt-tr').each((headRow) => {
    cy.wrap(headRow).within(() => {
        cy.get('.rt-th').each((cellDataHead) => {
            cy.log(cellDataHead.text())
            tableHeaders.push(cellDataHead.text().trim())
        })
    })
}).then(() => {
    cy.log(tableHeaders)
    cy.log(tableHeaders.indexOf("Tracking No."))
    cy.log(tableHeaders.indexOf("Merchant Name"))
})

Use regular expression to validate a ten-digit number

See the script down below:

1.For 10 digit number:

cy.get('#<class-name-of-text-input>').contains(/^\d{10}$/)

2.For 10 digit number containing all 0-9 digits

cy.get('#<class-name-of-text-input>').contains(/^(?!.*(.).*\1)\d{10}$/)

Check Regexr to validate the expression.

I have a similar requirement, except I'm reading an application config file (which lives within the app assets folder).

I read it with a require like so,

const runtimeConfig = require('../../../src/data/my-config');

This works well, I can then proceed to test with expectations based on the file contents.

So, your code would be something like this

const expectation = require('path/to/expectation.json');

describe(`Test the app `, function() {
  Object.keys(expectation).forEach(function(pageName) {
    it(`for page ${pageName}`, function() {
      gotoPage(pageName);
      var pageData = getDataFrompage();
      expect(pageData).to.equal(expectation[pageName]);
    })
  })
})

readFile()

Trying cy.readFile(), you get get this error message

Uncaught Error: Cannot call "cy.readFile()" outside a running test.

You can stop this error by wrapping the read in a before like so

let runtimeConfig;
before(function(){
  cy.readFile('./src/data/my-config.json').then( fileContents => {
    runtimeConfig = fileContents;
  })
})

but unfortunately Cypress does not wait for the read to complete before proceeding to test.

fixture()

I also tried the fixture pattern shown in example.spec.js

context('Files', function(){
  beforeEach(function(){
    cy.visit('https://example.cypress.io/commands/files')
  })
  it('cy.fixture() - load a fixture', function(){
    // Instead of writing a response inline you can
    // connect a response with a fixture file
    // located in fixtures folder.

    cy.server()

    // https://on.cypress.io/fixture
    cy.fixture('example.json').as('comment')

    cy.route(/comments/, '@comment').as('getComment')

    // we have code that gets a comment when
    // the button is clicked in scripts.js
    cy.get('.fixture-btn').click()

    cy.wait('@getComment').its('responseBody')
      .should('have.property', 'name')
      .and('include', 'Using fixtures to represent data')

but could not get it to work with my config file even when copying it to the /cypress/fixtures folder.

Also, this feels a quite hacky - if I understand this code correctly, it is turning the file read into a pseudo route navigation so that Cypress can wait on it.

This pattern is complicated and certainly does not lend itself to the dynamic testing scenario you describe.

Can you just wait on the filename?

cy.contains('[data-render-row-index="1"] > [data-col-index="1"]', filename, 
  { timeout: 30_000 }
)

If the reload is needed to get the correct row entry, a repeating function is a possibility

function refreshForData(filename, attempt = 0) {

  if (attempt > 30 ) {            // 30 seconds with a 1s wait below
    throw 'File did not appear'
  }

  // Synchronous check so as not to fail
  const found = Cypress.$(`[data-render-row-index="1"] > [data-col-index="1"]:contains('${filename}')`)

  if (!found) {
    cy.wait(1_000)
    cy.get('Reload button').click()
    cy.get('Spinner').should('not.be.visible')
    refreshForData(filename, ++attempt)
  }
}

refreshForData(filename)  // pass in filename, function can be globalized
                          // maybe also pass in selector?

To expand on @JosePita's idea, you can set up glob patterns in scripts (package.json) and by-pass the multitude config files he was concerned about.

For example, these work on my system,

"scripts": {
  "cy:open": "cypress open",                              // all files
  "cy:user": "cypress open -c testFiles=user/**/*",       // just the user folder
  "cy:error": "cypress open -c testFiles=**/*error*.js",  // files with keyword 'error'

There's a search bar at the top of the Cypress runner, where the tests are listed, but search is all it does.

Pressing the Run all specs button runs the full set regardless of search results.

If you want to run a subset, specify the testFiles config option on the command line.