escaping form a modal like this

cy.get('body').click(0,0);

makes the next command fail

any other way to escape modals?

or using cy.get(".v-card__title").type('{esc}');

fails the next comman that is choosing a dropdown option

but when I do not open the modal and ignore the step of opening the modal, the dropdown choosing option works

what is going on ?

Hello, Can someone help me here? Scrolling horizontally to find an element is failing Test code to reproduce it('should scroll right & click on march column', () => { cy.visit('https://www.ag-grid.com/example.php'); cy.get('div.ag-center-cols-viewport div[row-id="0"] div[col-id="mar"]') .scrollIntoView() .click(); }); I have also tried scrollTo('right'), but in my case the element's position is not the extreme right.

What about having a close button on the actual modal? Either an 'x' in top right/left corner, or a close button at the bottom. It seems like when you try to escape the modal in those ways, the modal is actually still being shown. Are you using the Cypress GUI? If the modal is still showing then the modal is probably still in the way of the dropdown component I'd be interested to see the exact error though

Hi, i'm having an issue when listening for events inside my cypress integration tests. example of a vue component i want to check {{ divResult}} I want to validate if the extroverted-div emitted its event and want to check the content inside the event. I already tried to do this with the good old event listeners combined with cy.get but it seems that the listeners wont be executed. thanks in advance

I found out that the event access works usinng Kuker also for vue apps, asserting is also confortable using some tweaks to the given code. https://www.cypress.io/blog/2019/03/20/using-events-emitted-from-your-application-during-end-to-end-tests/

How can i import the awsconfig file (ES6 exported) into plugin/index.js (commonjs)?

The awsconfig file is dynamically generated (and used in a number of different places in my code), so doing a module.exports is not an option

nybody running cypress with Google Cloud Firestore recently? Inside cypress adding a document takes as much as 45 seconds for xhr response. Outside of cypress (local serve of app) it takes about 1.5 seconds. Does cypress do anything internally that could be causing xhr slowness?

Hi guys, I'm using Cypress 9.2.0 and cypress-react 5.12.0 I'm having somme issues to properly configure excludes and includes in

tsconfig

I'm using Cypress for E2E and Component testing so I have

.spec.tsx

files living alongside my

Component.tsx

file I have this structure

cypress/*
src/*

and I have a

tsconfig

at the root and another

tsconfig

inside

cypress

This is my

tsconfig

inside

cypress

json
{
  "extends": "../tsconfig.json",
  "compilerOptions": {
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": [
      "cypress",
      "node",
      "cypress-file-upload",
      "cypress-real-events",
      "cypress-plugin-tab"
    ],
    "isolatedModules": false
  },
  "include": ["../node_modules/cypress", "./**/*.ts", "**/*.spec.ts"]
}

and this is

tsconfig

in the root, I have this

json
{
  ...
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx"],
  "exclude": [
    "node_modules",
    "api",
    "src/**/*.test.ts",
//    "cypress/**/*.ts",
//    "cypress/**/*.tsx",
//    "src/**/*.spec.tsx"
  ]
}

The thing is that if I dont comment these 3 lines then when I run

tsc --project tsconfig.json --pretty --noEmit

then I have a bunch of errors related to cypress. However, if I uncomment these 3 lines, then I have no more errors when I run

tsc

but now I can't run any E2E tests, it's complaining that there are not tests to run Error: Webpack Compilation Error /Users/xxx/xxx/cypress/tsconfig.json [tsl] ERROR TS18003: No inputs were found in config file 'tsconfig.json'. Specified 'include' paths were '["../node_modules/cypress","./**/*.ts","**/*.spec.ts"]' and 'exclude' paths were '["../node_modules","../api","../src/**/*.test.ts","../cypress/**/*.ts","../cypress/**/*.tsx","../src/**/*.spec.tsx"]'.

How can I exclude test files from

tsc

and have them being picked up by Cypress?

Looking at your test, you are scrolling then clicking, maybe what you want to do is scroll the parent then click on the child. It's the parent that needs to scroll, not the child

"It's the parent that needs to scroll, not the child" => I think you are talking about ScrollTo. ScrollTo should be applied on parent, scrollIntoView can be applied on child too AFAIK (https://docs.cypress.io/api/commands/scrollintoview#Examples),

Is anyone aware of sound reasoning for maintaining two login commands, one that doesn't use cy.session, and one that does, for reasons like test run time savings? Specifically: use the non-session version in specs that only have one test (it() block) and only use the cy.session version in specs with multiple it() blocks? I wouldn't think this would save any time beyond a few milliseconds, but there seems to be some belief on my team that this is a good idea, so I'm wondering...

@User would you have any insight on this? To be clear, I'm not in favor of two commands. I want better confidence that there is no real reason to practice this, or an explanation of why there might be reason to do so.

I don't use cy.session command myself, prefer to use my.dataSession for everything

To be exact, you mean https://github.com/bahmutov/cypress-data-session ? I'd never read about that until you mentioned it. You basically use it to save auth data as well as any other data saved in the browser?

If anyone else could still speak to whether there are performance tradeoffs/concerns between using cy.session or not though, I'd much appreciate that.

Hey guys, I'm new to Cypress and I am testing an E-Commerce website that has a lot of API requests and I think that causes Cypress to crash, the browser is unable to type the

Email

during the log-in process. Could anyone give an idea on how I could solve this issue? This is the URL: https://www.vitalproteins.com/account/login

Yup that's the one, see the slides at https://slides.com/bahmutov/flexible-cypress-data for the derivation and use cases

This is what I see when I first navigate to that url. Are you sure none of these popup type things are getting in the way? As for all the API requests, I think we'd need more info there. What is with the 100s of 'recording' POSTs that seem to happen with simple mouseover events and much more? Gives the site a feeling of not being legitimate or maybe some poorly implemented customer usage software (like pendo) to me...

Sorry, I should have been more specific, I will share with you the script and more details of the issue that I am having.

Well, I ended up doing a bit of a test of my own in regards to cy.session(). I setup a real simple test that logs in and then navigates to a page behind the authentication and make sure it loads. I ran the test with the exact same login command, but 20 times I did it with cy.session, and another 20 times I did it without cy.session. I ran all these headlessly and as completely separate runs (meaning the browser was opened newly every time, otherwise cy.session's primary purpose would kick in and save the session, skip logging in every time and of course be way faster than running without cy.session). The average time to run the test is about 18.5 seconds. The difference between the two averages with and without cy.session is only 25ms, and it was actually in favor of cy.session anyway. 25ms is easily within the 'noise' variation for an 18s long test. So I think it is clear that not using cy.session to try to save 'test execution time' is a really pointless endeavor. In case anyone else wonders 🙂

Thank you for looking into this. I really appreciate it, I am not sure why this is taking this long with Cypress, manually takes less. Jave you seen a case like this?

Do you think are all those requests?

I was hoping for more info like you said. But the requests seem a little odd to me, though I'm absolutely not an expert on behavior tracking software. The primary domain of all those requests is contentsqaure, which is a customer behavior tracking software indeed: https://go.contentsquare.com/ I just don't understand why they happen so frequently, even when all I do is run my mouse over buttons and fields. Could very well be a normal behavior for software like this, but seems a little excessive to me... I wouldn't think it behaved any different for cypress as it does manually as well, so the API requests may very well not be the root problem as to why cypress does not seem to be working... but I wouldn't rule it out yet either.