How to use createCache method in Cypress

In case someone will come across this issue, you need to pass response as one of the parameters, like this:

cy.route({
  method : 'GET',
  url: 'users',
  status: 400,
  response: {}
});

instead of

cy.get('input').type('now')

try

cy.get('.input').type('now')

because you are looking for the class name not for the tag

A couple of problems with the custom command

• to make sure you wait on the results of .each(), must return the promise created bt Cypress.Blob.canvasToBlob() chain.

• follow the .each() with a .then() to ensure completion, and return `bufferMap here.

Problems with .task()

• it does not like being called within the custom command, so call it after

  CypressError: cy.then() failed because you are mixing up async and sync code.

• it does not like a Map() object as a parameter, convert to a plain object

Test

describe('leaflet', () => {

  it('processes', () => {

    Cypress.Commands.add('renderCanvasMatrixToPng', {prevSubject: true}, (subjects, savePath) => {
      const bufferMap = new Map();
      cy.wrap(subjects)
        .each((canvas, i) => {
          return Cypress.Blob.canvasToBlob(canvas.get(0))   // <- add return here
            .then(blob => Cypress.Blob.blobToArrayBuffer(blob))
            .then(buff => {
              var view = new Int8Array(buff);  // not sure why this is needed
              const buffer = Buffer.from(view);

              // get coords here
              const coords = 1000 + i // for purpose of demo
              bufferMap.set(coords, buffer)
            })
        })
        .then(_ => {                           // <- wait for previous to complete
          console.log('bufferMap inside command', bufferMap)  // [[Entries]]
                                                              //  0: {0 => Uint8Array(27209)}
                                                              //  1: {1 => Uint8Array(1179)}
          return bufferMap;
        })
    });

    cy.visit('http://cartodb.github.io/Leaflet.CanvasLayer/example.html')

    cy.get('canvas').renderCanvasMatrixToPng().then(bufferMap => {
      console.log('bufferMap outside command', bufferMap)  // [[Entries]]
                                                           //    0: {1000 => Uint8Array(25218)}
                                                           //    1: {1001 => Uint8Array(1179)}
      const asObject = Object.fromEntries(bufferMap);
      cy.task('mergeImages', { buffers: asObject, savePath: 'cypress/snapshots' });
    })

  })
})

Task for demo

module.exports = (on, config) => {
  ...
  on('task', {
    mergeImages(options) {
      const { buffers, savePath } = options;

      console.log('buffers', buffers);
      /* In terminal

        buffers {
          '1000': {
            type: 'Buffer',
            data: [
              137,  80,  78,  71,  13,  10,  26,  10,   0,   0,   0,  13,
              ... 33137 more items
            ]
          },
          '1001': {
            type: 'Buffer',
            data: [
              137,  80,  78,  71,  13,  10,  26,  10,   0,   0,   0,  13,
              ... 1079 more items
            ]
          }
        }
      */

      return null;
    }
  })
}

Alternative command (my preference)

Cypress.Commands.add('renderCanvasMatrixToPng', { prevSubject: true }, (subjects, savePath) => {
  const bufferPromises = Array.from(subjects).map(canvas => {
    return Cypress.Blob.canvasToBlob(canvas)
      .then(blob => Cypress.Blob.blobToArrayBuffer(blob))
      .then(buff => {
        const view = new Int8Array(buff);
        const buffer = Buffer.from(view);
        return buffer;
      })
  })
  return Promise.all(bufferPromises).then(buffers => {
    const bufferMap = new Map();
    buffers.forEach((buffer, i) => {
      // get coords here
      const coords = 1000 + i // for purpose of demo
      bufferMap.set(coords, buffer)
    })
    return bufferMap;
  })
});

The jQuery .index() method is useful here

Search for a given element from among the matched elements

cy.contains('table thead th', 'Contact')
  .then($th => $th.index())
  .then(contactIndex => {
    cy.get('table tbody td').eq(contactIndex).should('contain', 'Maria Anders')
  })

Updated for Cypress v7.0.0 Released 04/05/2021

The change-log shows from this release the intercepts are now called in reverse order

Response handlers (supplied via event handlers or via req.continue(cb)) supplied to cy.intercept() will be called in reverse order until res.send is called or until there are no more response handlers.

Also illustrated in this diagram from the documentation

When you set up identical intercepts, the first one will grab all the calls. But you can wait on the first alias multiple times.

Here's a (reasonably) simple illustration

spec

Cypress.config('defaultCommandTimeout', 10); // low timeout
                                             // makes the gets depend on the waits 
                                             // for success

it('never fires @call2',()=>{

  cy.intercept({ pathname: "/posts", method: "POST" }).as("call1")
  cy.intercept({ pathname: "/posts", method: "POST" }).as("call2")

  cy.visit('../app/intercept-identical.html')
  
  cy.wait('@call1')                               // call1 fires 
  cy.get('div#1').should('have.text', '201')

  cy.wait('@call2')                               // call2 never fires
  cy.wait('@call1')                               // call1 fires a second time
  cy.get('div#2').should('have.text', '201')

})

app

<body>
  <div id="1"></div>
  <div id="2"></div>
  <script>

    setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts', {
        method: 'POST',
        body: JSON.stringify({ title: 'foo', body: 'bar', userId: 1 }),
        headers: { 'Content-type': 'application/json; charset=UTF-8' },
      }).then(response => {
        document.getElementById('1').innerText = response.status;
      })
    }, 500)
  
    setTimeout(() => {
      fetch('https://jsonplaceholder.typicode.com/posts', {
        method: 'POST',
        body: JSON.stringify({ title: 'foo', body: 'bar', userId: 2 }),
        headers: { 'Content-type': 'application/json; charset=UTF-8' },
      }).then(response => {
        document.getElementById('2').innerText = response.status;
      })
    }, 1000)

  </script>
</body>

You can see it in the Cypress log,

Use cy.log(yourTextHere). That should work.

Try this instead:

cy.wrap(null).then(()=>{cy.log(array.length)})

I'm currently working at a large well-known company on our test tools and frameworks team. So while I'm no expert, it is something that's part of my job. I'm going to be talking specifically about web testing. Testing is somewhat different for native apps like iOS and Android and I'm not super familiar with those aspects.

The terminology between e2e (end to end) and integration tests is somewhat interchangeable, while unit tests have a more specific definition.

Generally e2e/integration tests should be runnable in dev and production environments. Depending on your setup, your dev environment is probably using some semi-frequently updated snapshot of your production db. In other cases, your local environment may be hitting the actual production db. There are pros/cons to both approaches, but it largely depends on the scale of your company or project. For example, if you're at a large company with dedicated teams you can see many changes a day hitting production databases vs a small team where a weekly snapshot of the prod db is probably good enough for testing locally. i At the base level, all integration tests should be treated as real. When dealing with web apps there are lots of other factors we have to take into account like different web browsers, network activity / availability, etc. So mocking out data for api calls would allow for super fast testing, but then adds another level of complexity with making sure the mocks stay up to date with the real-world database.

Running integration tests locally should more or less be doing the same thing against your dev server that they will be doing against staging and production. With the exception of having the app detecting whether its running in a dev, staging, or production environment to switch out URL's and various credentials, the app should be expected to behave exactly the same way.

In regards to your question about authentication, the answer is yes. Lets look at 2 examples that show different considerations.

Suppose your project is very small. You create some real accounts on production and your db gets snapshotted weekly for use in your local dev environment. You just run your integration tests with one or more of those users as needed. Since the local tests are only hitting your local db, you don't need to worry about the data being generated since it won't affect production. Other engineers on your team can use the same user(s) and not worry about it. If one engineer makes some changes to the db schema, ORM, etc then everyone just gets a new copy of the db snapshot and continues working.

Now for the other extreme. Suppose your project is very big. Millions of users and hundreds of employees all collectively making changes to the codebase and db every day. There are all kinds of ways that infrastructures are setup to handle various engineering tasks. There's too much data and the db changes too often to make using local snapshots feasible. At this scale, you're probably doing continuous integration and running your tests on every commit. You want to do that so that incoming changes don't make it to production and cause major problems. You're probably running your local dev environments against either a constantly updated staging database, or perhaps even against your production db itself. (Try planning for the staging db as it avoids a lot of other problems.)

Now, having just a small set of dedicated test users starts to be a problem. Tests are running all the time, both automated and by dozens of engineers all working on their own bits of work. Since the staging db is probably shared, you easily start getting weird conflicts as the same test user is doing all kinds of things and starts causing tests to fail. A good solution I've seen for this is a kind of test account checkout server. You create say 100 or 1000 (or more) test user accounts. When your integration tests run, they literally check out a test user account from the server. When the tests are done, the integration tests clean up whatever changes they made on that user and tell the checkout server that the user is free again. Then it randomly gets checked out by someone/something else and the cycle continues.

So the take aways that related directly to your question:

1. You should always have dedicated test user accounts that are exactly the same as regular user accounts, just dedicated to testing.
2. Depending on scale of team and project, if small a few dedicated accounts is fine. If working on a much larger scale, you need many more dedicated test accounts and probably want an automated service that allows individual test runs to checkout users as needed.
3. Tests should always clean up after themselves. If a test creates a TODO that gets stored in the db. When the test is done running, that TODO should be deleted from the db. If you aren't constant about this, you'll eventually run into bugs and issues where data is inconsistent. God forbid this happens in production.
4. Only worry about mocking data for unit tests, unless you're working in a very good and dedicated engineering environment where you have people dedicated to keeping the db mocks up to date all the time. If you can do that, your integration tests will be very fast and you don't really have to worry about the db stuff as much. But its hard to maintain this over time without dedicated support.

Apply a .filter() with a jQuery expression:

cy.get('li[data-testid="wrapper"]')
  .filter((i,li) => Cypress.$(li).find('p').length === 3 )
  .first()
  .click()

These alternatives also work:

.filter((i,li) => Cypress.$(li).find('.selections').children().length === 3 )
.filter((i,li) => Cypress.$(li).find('[data-testid^="selection"]').length === 3 )