Not, did not work

hi. i'm new to cypress. i experienced something that seemed strange to me. when i ran a test from the test runner, the aut preview did not display some of the html elements of the app. what could be the issue? thanks..

Cypress only executes/renders the page until all assertions are checked and continues with the next test... So it's not really an issue but how testing with cypress works

thanks HansM the first screenshot shows the web elements in a regular instance of chrome. the second screenshot is the aut preview in cypress where some of the web elements are missing. this is what i was referring to. i tried to click on one of the web elements but i'm getting an assertion error that the element was not found, which is shown in the third screenshot. i'm assuming the assertion error was thrown because the web elements are not present in cypress aut preview.

Hi Team, how do I produce single mochawesome report after running the test parallel in gitlab ci

I did some manual runs and they are deterministic to some extend. For sure I need some reliable tool to determine what are ACTUAL values of ping, download and upload speed. Then I am thinking of comparing these values with some level of margin of error of course. The problem is I didn't find any tool that I could possibly rely on. Maybe you heard of some?

Ok, so it's actually an assertion error... To narrow it down you should open cypress in visual mode (headless could be an issue in some cases), and if that doesn't change things you might want to switch the browser there, there are slight changes between browsers after all. Also are you maybe relying on cookies and/or local storage for those elements? that's also a likely candidate for issues as those will be emptied on every test

Thanks HansM. I'm reading up on visual testing now. i will check with the developers abbout the last point you made. thanks again.

Hey guys, Cypress recalls elements that were already used and failed my test because of that, any idea why?

Found the issue, it was related to using aliases

assuming you are not using Cypress Dashboard, you are manually parallelizing, and now you want to run a report First, strongly advise against this "manual" work. It will take exponential amount of person hours to implement and maintain vs paying a fraction of that amount for a service that works so well and has plenty additional features that make it a draw (ex: flake management). We did this manual work partially at my previous job. In Chicago we used the dashboard, in EU they did not want to pay for it, and worked in a half working solution for 3 years... It was someone's part time job for 3 years to implement and maintain it and the end result was something that works terribly half the time, and doesn't work the other half. Assuming there are labor laws and what not that force your hand (busy work need to be invented...) effectively reports need to be merged after parallelization. Looks like this stageA --> stageB job1 ----> get artifacts and merge reports job2 job3 here's a good post about it https://kristijan-pajtasev.medium.com/cypress-merging-multiple-mochawesome-reports-3eb8fcaaf32c

did not work ... as in which step? 1. POST a user 2. GET that user, ensuring it got created 3. Load the UI, not find the user You can always "tame" eventual consistency with this shotgun solution https://github.com/bahmutov/cypress-recurse. Apply it on the step that doesn't work can't help further unless the repo can be shared or there is a simple reproduction

"deterministic to some extent" ... probably not worth it Effectively you need to run from the same location against the same server all the time. Testing the UI, those are all abstracted. What is the end goal? What is the purpose? To performance test an app, an api? Really you can cover all this with a 2 fold strategy: 1. For UI, use lighthouse (has a Cypress plugin) 2. For API, which is always the real bottleneck, use k6 Take a look at https://github.com/NoriSte/ui-testing-best-practices/blob/master/sections/advanced/performance-testing.md

those get tricky, be careful There are a few ways to use them but, for selectors, just go with helpers or commands https://dev.to/muratkeremozcan/functional-test-patterns-with-cypress-27ed

shotgun solution?!!! You take it back @magnificent-finland-58048

ahaha sorry maestro, it's just too good

Thank you very much, will take a look at that

Yes, you’re right, they are tricky, nice article!

Hi there, I have a question regarding the use of Cypress for api calls. Our issue is this. We have many unnecessary API calls happening when we load a page. So I want to avoid this by writing test cases. So far I use this way. Intercepting certain calls and counting the number of the times they are called and then assert if they are called more than required. Do you recommend any other way? Also, suppose that I do not want to tackle this mess and just focus on my automation from functionality point of view. Could there be a way to ignore those unnecessary API calls to render the app faster?

You could stub the response by using ‘req.reply()’ within your call to

intercept()

. I recently shaved 10 seconds off a spec using this approach (16s down to 6)

So you will force the empty reply right? Well that is a good idea. Thank you.

Not necessarily 🙂 You can also specify a reply body. That helped me to stub out a lot of our upstream dependencies

In my case, they have to be empty actually because I do not really need their responses. They are called for no reason.

Well yeah, you can certainly pass an empty body for the reply. Sounds like an odd application behaviour though 😅

Indeed 🙂

How to get list of tags with cypress-cucumber-preprocessor?

Cypress preview displays UI until you meet all assertions, if you test has been finished that’s the reason. Try to add another assertion to make sure the UI you are expecting to see is there.

I think Cypress is designed to stop if an assertion fails. Playwright has a feature to support to continue execution even if an assertion fails

Thanks bro! i'll remake here

I'm having an issue dealing with a

confirm

dialog initiated from within an iframe.

cy.on("window:confirm", ...

doesn't catch the call because of the iframe - and also Cypress doesn't autoconfirm. I'm using the

getIframeBody

approach from https://www.cypress.io/blog/2020/02/12/working-with-iframes-in-cypress/ to deal with elements in the iframe, but I'm not sure how to tell

cy.on

to catch javascript happening in the iframe's context. Any suggestions?