I guess you have to understand that Cypress commands run asynchronously from the javascript in the test.

Move the .type() inside the .then() so it happens after you modify the value

let bankBranch = 'Base Data';

cy.get("#bankBranch").then($el => {
  bankBranch = bankBranch.replace(/\s+/g, '+');
  cy.wrap($el).type(bankBranch)
})

There are other refactors, I recommend playing around.

// replace the space early
let bankBranch = 'Base Data'.replace(/\s+/g, '+')

cy.get("#bankBranch")
  .type(bankBranch)

let bankBranch = 'Base Data';

cy.get("#bankBranch").then($el => {
  bankBranch = bankBranch.replace(/\s+/g, '+');
  // pass on the element
  return $el
}).then($el => {
  // deferring the .type() command
  cy.wrap($el).type(bankBranch)
})

Steve's answer actually helped me to end up with this code in cypress/plugins/index.ts.

import dotenv from 'dotenv';

dotenv.config({ path: '.env.local' });

import { encryptSession } from 'utils/sessions';

/**
 * @type {Cypress.PluginConfig}
 */
const pluginConfig: Cypress.PluginConfig = (on, config) => {
  on('task', {
    encryptSession: (session: {
      issuer: string;
      publicAddress: string;
      email: string;
    }) => encryptSession(session),
  });
};

export default pluginConfig;

Then in cypress/support/commands.ts.

Cypress.Commands.add(
  'loginWithCookie',
  ({
    issuer = 'some-issuer',
    publicAddress = 'some-address',
    email = 'some-email',
  } = {}) => {
    const session = { issuer, publicAddress, email };

    return cy.task<string>('encryptSession', session).then(token => {
      return cy.setCookie('my-secret-token', token).then(() => {
        return session;
      });
    });
  },
);

There's some examples in the documentation, for example

cy.request('POST',"localhost:8080", {...})
  .its('body').should('include', 'HELLO WORLD%')

An live example for @jjhelguero

cy.request({
  method: 'POST',
  url: 'https://jsonplaceholder.typicode.com/posts',
  body: "Hello World", 
  header: "Content-Type:application/json"
})
.its('body')
.should('have.property', 'id', 101)

As mentioned in comments, you have been given the wrong syntax in the previous answer.

Cypress task is a command that returns a Chainable. You need to use .then() to get the value, so the calling order needs to be different.

it('returns an array containing a found ticket summary', () => {

  cy.task('getTicketBySummary', { issues: mockedTickets, summaryTitle: 'This is ticket number 1' })
    .then(result => expect(result).to.eq(mockedTickets.data.issues[0]) );

});

I made a thing that works :)

envTypeWriter.mjs

import dotenv from 'dotenv'
import fs from 'fs'

const env = dotenv.config({ path: '.env.local' }).parsed
const typeText = `type TEnvKey =\n  | "${Object.keys(env).join('"\n  | "')}"`

fs.writeFileSync('env.d.ts', typeText)

package.json

"scripts": {
    ...
    "types": "node envTypeWriter.mjs"
  },

Then I just do yarn types (and >Reload Window) in vscode).

Don't change my variables that often so this is fine.

Updated version

template:

utils/env.ts

export default function env(key: TEnvKey): string {
  try {
    // have to try catch because of Cypress reference error
    return Cypress.env(key);
  } catch {
    switch (key) {
      // START OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT

// this part will be replaced

      // END OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT
      default:
        return undefined;
    }
  }
}

// START OF AUTO GENERATED TYPES -- DO NOT REMOVE OR EDIT THIS COMMENT
// this will be replaced

envTypesWriter.ts

import { config } from 'dotenv'
import { writeFileSync, readFileSync } from 'fs'

const envLocal = config({ path: '.env.local' }).parsed // NOTE: Script has to be executed from the project root
const typeText = `type TEnvKey =\n  | "${Object.keys(envLocal).join('"\n  | "')}"`

const casesText = Object.keys(envLocal).reduce((acc, key) => {
  acc += `      case '${key}':\n`
  acc += `        return process.env.${key}\n`
  return acc
}, '')

const filePath = 'utils/env.ts'
let text = readFileSync(filePath, { encoding: 'utf8' })
console.log(`reading ${filePath}`)

if (!text) throw 'nothing read'


const casesStartLineMarker =
  '// START OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'
const casesEndLineMarker =
  '      // END OF AUTO GENERATED CASES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'

text = `${
  text.split(casesStartLineMarker)[0]
}${casesStartLineMarker}${casesText}${casesEndLineMarker}${
  text.split(casesStartLineMarker)[1].split(casesEndLineMarker)[1]
}`

const typesLineMarker = '// START OF AUTO GENERATED TYPES -- DO NOT REMOVE OR EDIT THIS COMMENT\n'
const [untouchedCode, _types] = text.split(typesLineMarker)
const updatedText = `${untouchedCode}${typesLineMarker}${typeText}`

writeFileSync(filePath, updatedText, 'utf8')

In similar situation you can use cy.route() which grab the network request and wait for it. In your case, the route will grab the n/w req and wait for the "Find me" request to get processed completely so that you can proceed with the next filter action.

Steps: Open the chrome console, navigate to network tab, filter for XHR request. Now click on the ''Find me'' button in you page. You can see usually a GET request, for example if the request looks as follows, https://example.com.au/v1/api/listview?page=2 Please copy the url from /v1/api/... and add into the url value of cy.route() as below.

note: On click on Find me button, see its a GET or POST request, usually it will be GET request, check if the url has any encoded value, if it has encoded value you have to use decodeURIComponent() and the pass the url inside as follows >> url:decodeURIComponent('**/v1/api/listview?page=2**'),

beforeEach(()=>{
    cy.server();
    cy.route({
     method: 'GET',
     url:'**/v1/api/listview?page=2**',
     delay: 2000
    }).as('getLoadNewView');
  })

    it('Route waiting for loading the new view for filter action', () => {
      cy.get('[data-cy="search"][data-component="input_box"]').type('Find me{enter}')
      cy.get('[data-name="Find me"]').contains('Find me').click()// Should load a new view 
      cy.wait('@getLoadNewView');
      cy.get('[data-cy = "filter"]').click();
      })

As far as I know, this would be the "Cypress" way to access data stored in a json file.

ref: https://docs.cypress.io/api/commands/fixture.html#Accessing-Fixture-Data

cy.fixture('user').then((user)  => {
    var name = user.name
    var pass = user.password
})

Where 'user' is /fixtures/user.json

{
    "name": "username",
    "password": "password1234"
}

This issue has been resolved. Thanks to @Mr.J. This had nothing to do with fs-extra. The entry point in docker file was not correct and I had to modify that. After modifying that, it worked fine.

If at all you have this issue, 1. Try installing fs-extra inside node_module. 2. please check the path in the cypress config file. 3. Check the path in docker file.

What distinguishes unit-tests and integration-tests (and then subsystem-tests and system-tests) is the goal that you want to achieve with the tests.

The goal of unit-testing is to find those bugs in small pieces of code that can be found if these pieces of code are isolated. Note that this does not mean you truly must isolate the code, but it means your focus is the isolated code. In unit-testing, mocking is very common, since it allows to stimulate scenarios that otherwise are hard to test, or it speeds up build and execution times etc., but mocking is not mandatory: For example, you would not mock calls to a mathematical sin() function from the standard library, because the sin() function does not keep you from reaching your testing goals. But, leaving the sin() function in does not turn these tests into integration tests. Strictly speaking, you could even have unit-tests where some real network accesses take place (if you are too lazy to mock the network access), but due to the non-determinism, delays etc. these unit tests would be slow and unreliable, which means they would simply not be well suited to specifically find the bugs in the isolated code. That's why everybody says that "if there is some real network access, it is not a unit-test", which is not formally but practically correct.

Since in unit-testing you intentionally only focus on the isolated code, you will not find bugs that are due to misunderstandings about interactions with other components. If you mock some depended-on-component, then you implement these mocks based on your understanding of how the other component behaves. If your understanding is wrong, your mock implementations will reflect your wrong understanding, and your unit-tests will succeed, although in the integrated system things will break. That is not a flaw of unit-testing, but simply the reason why there are other test levels like integration testing. In other words, even if you do unit-testing perfectly, there will unavoidably remain some bugs that unit-testing is not even intending to find.

Now, what are integration tests then? They are defined by the goal to find bugs in the interactions between (already tested) components. Such bugs can, for example, be due to mutual misconceptions of the developers of the components about how an interface is meant to work. For example, in the case of a library component B that is used from A: Does A call functions from the right component B (rather than from C), do the calls happen while B is already in a proper state (B might not be initialized yet or in error state), do the calls happen in the proper order, are the arguments provided in the correct order and have values in the expected form (e.g. zero based index vs. one based index?, null allowed?), are the return values provided in the expected form (returned error code vs. exception) and have values in the expected form? This is for one integration scenario - there are many others, like, components exchanging data via files (binary or text? which end-of-line marker: unix, dos, ...?, ...).

There are many possible interaction errors. To find them, in integration testing you integrate the real components (the real A and the real B, no mocks, but possibly mocks for other components) and stimulate them such that the different interactions actually take place - ideally in all interesting ways, like, trying to force some boundary cases in the interaction (exchanged file is empty, ...). Again, just the fact that the test operates on a software where some components are integrated does not make it an integration test: Only if the test is specifically designed to initiate interactions such that bugs in these interactions become apparent, then it is an integration test.

Subsystem tests (which are the next level) then focus, again, on the remaining bugs, that is, those bugs which neither unit-testing nor integration testing intend to find. Examples are requirements on the component C that were not considered when C was decomposed into A and B, or, if C is built using some outdated version of A where some bug was still in. However, when climbing up from unit-testing via integration testing to subsystem testing and above, it is a challenge to stay focused: Only to have tests for bugs that could not have been found before, and not to, say, repeat unit-tests on subsystem level.